MySQL用户权限控制须用GRANT/REVOKE操作，遵循最小权限原则按库授权；分区表不支持分区级权限，需通过视图实现逻辑隔离；多租户场景应优先选用独立数据库而非分区表。
MySQL 用户级权限控制怎么做
MySQL 的权限管理核心在 mysql.user、mysql.db、mysql.tables_priv 这几张系统表，但日常操作不建议直接改表，必须用 GRANT 和 REVOKE 语句——否则权限缓存不同步，改了也不生效。
常见错误是只给 SELECT 权限却忘了加 USAGE（连接权限），导致用户能连上但查不了任何库；或者用 GRANT SELECT ON *.* 授予全局权限，结果暴露了 mysql 系统库。
- 最小权限原则：按库授权，比如
GRANT SELECT, INSERT ON myapp.* TO 'app_user'@'192.168.1.%' - 敏感操作单独控制：如
DROP、ALTER、CREATE USER必须显式授予，不会随ALL PRIVILEGES自动包含（除非指定WITH GRANT OPTION） - 权限生效需刷新：
FLUSH PRIVILEGES仅在直接改系统表后才需要；用GRANT后权限立即生效，无需刷新
如何限制用户只能访问特定分区表的某几个分区
MySQL 本身不支持“对分区授予权限”，GRANT 的最小粒度是表（table_level），不是分区（partition）。所谓“按分区控制访问”，实际得靠应用层或视图兜底。
典型做法是：建一个只暴露目标分区数据的视图，再给用户授权该视图。例如分区表 sales_2024 按 MONTH(created_at) 分区，你想让财务组只看 Q1 数据：
CREATE VIEW sales_q1 AS SELECT * FROM sales_2024 WHERE created_at BETWEEN '2024-01-01' AND '2024-03-31';
然后授权：GRANT SELECT ON mydb.sales_q1 TO 'finance'@'%'。
- 注意视图定义中不能含子查询或临时表，否则某些 MySQL 版本（如 5.7）会拒绝授权
- 分区裁剪（partition pruning）在视图里依然有效，只要
WHERE条件能命中分区键 - 不要依赖
INFORMATION_SCHEMA.PARTITIONS做权限过滤——它本身可被所有有SELECT权限的用户查到，不安全
分区表 + 多租户场景下的权限隔离难点
如果用分区表模拟多租户（比如按 tenant_id 分区），想做到租户间数据逻辑隔离+权限物理隔离，会遇到硬伤：MySQL 不支持“按分区设置 owner”或“动态分区掩码”。
真实生产中更稳妥的方式是：用独立数据库（tenant_001, tenant_002…）替代分区，再配合 GRANT ... ON tenant_001.* 控制。虽然库数量变多，但权限边界清晰、审计方便、备份恢复也粒度可控。
- 分区表适合解决单库内大表性能问题（如归档、快速删除旧分区），不适合做租户隔离
- 若坚持用分区，必须在应用 SQL 中强制带上分区键条件（如
WHERE tenant_id = ?），否则跨分区扫描会拖垮性能，且无法靠权限堵住漏查 - MySQL 8.0+ 的角色（
ROLE）能简化批量授权，但角色仍作用于库/表级，无法绑定到分区
常见权限相关错误信息怎么看
遇到权限报错，先看完整错误信息，重点识别关键词：
-
Access denied for user 'u'@'h' (using password: YES)：用户名密码或 host 不匹配，检查user表中host字段是否精确（%不匹配 localhost） -
SELECT command denied to user 'u'@'h' for table 't'：表级权限缺失，确认是否执行过GRANT SELECT ON db.t TO ...，而不是只授了库级 -
Table 'mysql.proc' doesn't exist：用户有EXECUTE权限但没SELECT权限查mysql库，调用存储过程失败——此时需显式授SELECT ON mysql.proc（MySQL 5.7）或升级到 8.0+ 改用mysql.routines
分区本身不改变权限模型，所有坑都来自混淆了“数据组织方式”和“访问控制机制”的边界。
