myisam表级锁不控制读写权限，权限由grant/revoke在用户层管理；其锁仅影响并发阻塞行为，如select间不互斥但会阻塞写操作；现代报表应避免myisam，优先选innodb从库或列存引擎。
MyISAM 表级锁对读写权限没实际控制力
MySQL 本身不通过存储引擎（如 MyISAM）实现“读写权限”的访问控制——权限由 GRANT/REVOKE 语句在用户账号层管理，和表用什么引擎无关。MyISAM 的“表级锁”只是并发控制机制，不是权限系统。你执行 SELECT 能否成功，取决于当前用户是否有 SELECT 权限；能不能写入，取决于是否有 INSERT/UPDATE/DELETE 权限，跟是不是 MyISAM 表毫无关系。
常见误解是：设成 MyISAM 就能“只读”或“禁止写入”。错。即使表是 MyISAM，只要用户有写权限，INSERT INTO mytable 一样会成功（并触发写锁）。
真正限制读写：用 GRANT 控制用户权限
要让某用户只能查报表数据、不能改，得在账号层面收窄权限。比如为报表用户 report_user 只赋只读权限：
GRANT SELECT ON `sales_db`.`monthly_report` TO 'report_user'@'%'; FLUSH PRIVILEGES;
这样该用户连 INSERT 都会报错：ERROR 1142 (42000): INSERT command denied to user 'report_user'@'%' for table 'monthly_report'。
- 别给
report_userALTER或DROP权限，否则仍可能删表或改结构 - 如果用视图封装报表逻辑，可以只对视图授
SELECT，底层基表权限完全不开放 - 权限生效需
FLUSH PRIVILEGES（改了 mysql.user 表后）或重启连接（部分版本自动刷新）
MyISAM 表级锁在报表场景的真实作用
MyISAM 的表级锁（读锁共享、写锁互斥）在报表场景中影响的是“并发执行时的阻塞行为”，不是权限。典型表现：
- 多个报表查询（
SELECT）可同时执行，因为都加读锁，不冲突 - 一旦有
INSERT或UPDATE开始写，所有后续SELECT会被挂起，直到写完成 - 反过来，一个长耗时的
SELECT（比如全表扫描统计）也会阻塞所有写操作
这意味着：在 MyISAM 表上跑报表，如果业务还在持续写入，报表查询可能卡住写入，引发上游超时。这不是权限问题，是锁争用问题——所以生产环境报表库普遍用 InnoDB（支持行锁+MVCC），或把报表导出到只读从库做查询。
为什么现在不该用 MyISAM 做报表主表
MyISAM 在现代 MySQL 中已基本被弃用（8.0+ 默认禁用，5.7 已标记为废弃）。它在报表场景的隐患远不止锁粒度粗：
- 崩溃后无法保证数据一致性，
REPAIR TABLE不一定救得回来 - 不支持事务，无法回滚误操作（比如手抖
UPDATE没加WHERE） - 没有 MVCC，长查询期间无法看到快照，容易读到中间状态（虽然 MyISAM 本身无事务，但用户常误以为“读不到脏数据”）
- 全文索引功能弱，且不支持中文分词（除非额外配插件）
真要做只读报表，优先选 InnoDB + 从库只读模式（read_only=ON），或用专用列存引擎如 ClickHouse。MyISAM 现在只适合极轻量、离线、无可靠性要求的临时表场景。
