grant语句要求目标数据库必须已存在，否则报error 1044或1146；正确顺序是先create database，再grant授权，最后flush privileges。
数据库不存在时 GRANT 会直接报错，必须先创建库再授权
GRANT 报错 ERROR 1044 或 1146 的真实原因
执行 GRANT SELECT ON mydb.* TO 'user'@'localhost'; 时如果提示 ERROR 1044 (42000): Access denied for user ... to database 'mydb' 或 ERROR 1146 (42S02): Table 'mydb.x' doesn't exist，根本不是权限问题本身，而是 MySQL 在解析 mydb.* 时发现 mydb 这个数据库压根没在磁盘上——它连 mydb 这个目录都没见过，自然无法完成授权校验。
- MySQL 的
GRANT语句要求目标数据库必须已存在（哪怕为空），否则语法校验失败 - 即使你用的是
root，只要mydb不存在，GRANT就不会执行，也不会自动创建库 - 错误信息里带
database 'mydb'字样，基本可以锁定是库缺失，不是用户或主机名写错
正确操作顺序：CREATE DATABASE → GRANT → FLUSH PRIVILEGES
授权前必须确保数据库已初始化。三步不能颠倒：
- 先登录 MySQL（不指定库）：
mysql -u root -p - 执行建库：
CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（加IF NOT EXISTS防重复报错） - 再授予权限：
GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'user'@'localhost'; - 最后刷新：
FLUSH PRIVILEGES;（否则新权限不生效）
注意：GRANT 中的 mydb.* 必须和 CREATE DATABASE 的名字完全一致，包括大小写（Linux 下敏感）。
自动化脚本里怎么安全处理
在部署脚本或初始化代码中，不能假设库一定存在。常见可靠写法：
- 用 MySQL 命令行一次性完成：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS mydb; GRANT ALL ON mydb.* TO 'user'@'localhost'; FLUSH PRIVILEGES;" - Python + pymysql 示例（需 root 权限）：
import pymysql<br>conn = pymysql.connect(host='localhost', user='root', password='xxx')<br>cursor = conn.cursor()<br>cursor.execute("CREATE DATABASE IF NOT EXISTS mydb")<br>cursor.execute("GRANT SELECT ON mydb.* TO 'appuser'@'localhost'")<br>cursor.execute("FLUSH PRIVILEGES")<br>conn.close() - 避免在同一个连接里先
USE mydb再GRANT——USE不影响GRANT对库名的校验逻辑，该报错还是报错
容易被忽略的坑：docker / 初始化卷场景
用 Docker 启动 MySQL 时，如果挂载了空数据卷，或者初始化 SQL 脚本执行顺序错乱（比如 GRANT 脚本比 CREATE DATABASE 脚本先执行），就会稳定复现这个错误。
- Docker Compose 中确保
init.sql里建库语句在授权语句之前 - 不要依赖 MySQL 容器启动时自动执行的
/docker-entrypoint-initdb.d/*.sql顺序——它按文件名排序，不是按内容顺序 - 最稳妥的做法：所有初始化逻辑写在一个 SQL 文件里，且
CREATE DATABASE放第一行
这个问题的本质不是权限配置难，而是 MySQL 把“数据库存在性”当作授权的前提条件来强校验。跳过建库直接授权，就像没盖地基就想装修——MySQL 不让动工。
