mysql不支持分区级权限，权限粒度仅到表级；需通过视图（如create view v_p2 as select * from tbl partition (p2)）或分表（如sales_202401）实现数据隔离。
MySQL本身不支持按分区限制账号权限
MySQL的权限系统（GRANT / REVOKE）粒度只到表级，不识别分区（partition）这个逻辑单元。哪怕你用PARTITION BY RANGE或LIST建了分区表，对用户执行GRANT SELECT ON db.tbl TO 'user'@'host'，该用户就能查整个表——包括所有分区。没有GRANT ... ON db.tbl PARTITION p2这种语法，也不存在分区级权限开关。
只能靠应用层或视图间接控制访问范围
想让某个账号“只看到p2分区的数据”，实际得绕道实现：
- 创建只映射目标分区的视图，比如
CREATE VIEW v_p2 AS SELECT * FROM tbl PARTITION (p2)（注意：MySQL 8.0+才支持PARTITION子句在SELECT中显式指定，且仅限于查询，不能用于DML） - 给账号授予该视图的
SELECT权限，而非原表权限：GRANT SELECT ON db.v_p2 TO 'user'@'host' - 确保原表权限未授予该账号——否则用户可直接查原表绕过视图
- 如果需要写入，视图必须是可更新的（满足MySQL视图可更新条件），且底层分区需支持对应操作；但多数分区场景下，
INSERT INTO v_p2可能失败，因为MySQL无法自动将行路由到指定分区（除非WHERE条件明确匹配分区键值）
分区键字段 + WHERE 条件是唯一可控的过滤手段
即使没视图，也可以靠权限+SQL约束配合实现软隔离：
- 确保账号只有
SELECT权限，无INSERT/UPDATE/DELETE - 在应用代码或中间件里，强制所有查询都带上分区键的
WHERE条件，例如WHERE dt = '2024-01-01'（假设按日期分区） - MySQL优化器会在执行计划里显示
partitions: p202401，说明确实只扫描目标分区——但这完全依赖SQL写法，不是权限机制保障的 - 风险点：只要用户能连上并执行任意
SELECT * FROM tbl，就会扫全表，且不会报错
替代方案：按业务拆成独立表 + 表级权限
如果分区纯粹为管理或性能服务，而安全隔离是刚需，更可靠的做法是放弃分区表，改用分表：
- 把原来一个分区表
sales拆成sales_202401、sales_202402等独立表 - 对不同账号分别授权：
GRANT SELECT ON db.sales_202401 TO 'user_a'@'%'，GRANT SELECT ON db.sales_202402 TO 'user_b'@'%' - 优势：权限真实生效，无绕过风险；劣势：失去分区自动维护（如
ALTER TABLE ... REORGANIZE PARTITION）、跨分区查询需UNION、DDL管理变重
MySQL的分区和权限是两条平行线，硬要交叉就得靠视图兜底或换架构。别指望SHOW CREATE TABLE里看到的PARTITION定义能带来任何访问控制能力。
