读写比决定架构决策：Com_select/(Com_insert+Com_update+Com_delete+Com_insert_select+Com_update_multi+Com_delete_multi)>5为读多写少，<0.01则buffer_pool过小需调大。
直接看 Com_select 和写操作总和的比值，别靠猜或代码行数统计。 这个比值决定你该不该上读写分离、要不要调 innodb_buffer_pool_size、甚至是否该换存储引擎（比如 MyISAM 在纯读场景下偶尔还有残余价值，但绝大多数情况不推荐）。
用 SHOW GLOBAL STATUS 算出真实读写比
MySQL 不会告诉你“读多还是写多”，它只记录每个语句类型被执行了多少次。关键不是你写了几个 SELECT，而是它实际被执行了多少次。
-
Com_select是真正的读次数（不含内部元数据查询） - 写操作要加总：
Com_insert+Com_update+Com_delete+Com_insert_select+Com_update_multi+Com_delete_multi - 执行命令：
SHOW GLOBAL STATUS WHERE variable_name IN ('Com_select', 'Com_insert', 'Com_update', 'Com_delete', 'Com_insert_select', 'Com_update_multi', 'Com_delete_multi'); - 计算公式：
Com_select / (写操作总和)—— 若结果 > 5，基本可认定为“读远多于写”；若
别被 Questions 或 Queries 指标误导
Questions 包含所有客户端发来的语句，比如 USE db、SET、SHOW VARIABLES，这些和业务读写完全无关；Queries 更宽泛，还包含存储过程内部语句、触发器等，无法对应到真实增删改查行为。
- 只信任以
Com_开头的计数器，它们是 MySQL 执行器层真正处理的语句计数 -
Com_select不等于“所有带 SELECT 的语句”——SELECT ... FOR UPDATE会被计入写类计数器，因为它涉及行锁和事务写入路径 - 如果应用大量用
INSERT ... ON DUPLICATE KEY UPDATE，它会计入Com_insert和Com_update各一次，写量会被高估，需结合慢日志和performance_schema.events_statements_summary_by_digest核对实际执行模式
配合 Grafana/监控图表看趋势，不是只看单点数值
瞬时比值意义有限。你要看的是：这个比值在高峰时段是否骤降？是否伴随 Threads_running 暴涨或 Innodb_row_lock_waits 上升？
- 如果读写比从 8 降到 2，同时
Slow_queries激增 → 很可能有未走索引的SELECT正在拖垮整个查询队列，此时引擎选型已不重要，先优化 SQL - 如果读写比稳定在 10+，但
Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests> 0.01 → 说明缓存命中率差，InnoDB引擎本身没问题，但 buffer pool 太小，优先调大而非换引擎 - 如果读写比长期 Handler_write 明显高于
Handler_read_*→ 写入密集型负载，InnoDB是唯一合理选择；MyISAM的表锁会成为绝对瓶颈
真正卡住人的，往往不是“该不该换引擎”，而是把 Com_select 当成 SELECT 语句数、把 Questions 当成有效 QPS、或者在 performance_schema 关闭状态下硬看 sys 库视图——这些都会让读写比失真，导致后续所有判断全偏。
