MySQL性能优化需系统性分层治理：从硬件配置、SQL与索引优化（如联合索引字段顺序、前缀索引）、表结构设计（拆分大字段、规范数据类型），到读写分离与分库分表策略。
MySQL性能优化不是靠一两个技巧就能解决的，关键在于系统性排查和分层治理：从硬件与配置基础、SQL质量、索引设计、表结构合理性，再到高并发与读写分离策略，每一层都可能成为瓶颈。
检查并调优MySQL基础配置
很多性能问题其实源于默认配置不适合当前业务负载。重点观察几个核心参数：
- innodb_buffer_pool_size：通常设为物理内存的50%–75%，它是InnoDB缓存数据和索引的核心内存区，过小会导致频繁磁盘IO
- innodb_log_file_size：日志文件不宜过小（如
- max_connections：根据应用连接池实际使用量设置，过高浪费资源，过低引发“Too many connections”错误
- query_cache_type / query_cache_size：MySQL 8.0已移除，5.7及更早版本若开启需谨慎——对写多读少或表更新频繁的场景反而降低性能
定位并优化慢SQL与执行计划
慢查询是性能下降最常见原因。先开启慢查询日志（slow_query_log=ON），设定合理阈值（long_query_time=1）收集问题SQL，再用EXPLAIN分析执行计划：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 重点关注type字段：ALL（全表扫描）、index（全索引扫描）需警惕；尽量达到range、ref、const级别
- 看rows预估扫描行数是否远超实际返回行数，过高说明索引失效或缺失
- 检查Extra列：出现Using filesort、Using temporary意味着排序/分组未走索引，应考虑联合索引或改写SQL
- 避免在WHERE子句中对字段做函数操作（如YEAR(create_time)=2024）、隐式类型转换、LIKE以%开头等，这些都会导致索引失效
科学设计索引与评估索引有效性
索引不是越多越好，而是要匹配高频查询模式。遵循“最左前缀原则”，优先覆盖WHERE、JOIN、ORDER BY、GROUP BY涉及的字段：
- 单列索引优先考虑区分度高的字段（如user_id > status）
- 联合索引要注意字段顺序：把过滤性最强、常用于等值查询的放左边，范围查询（>、BETWEEN）字段放右边，排序字段尽量放在最后
- 定期用sys.schema_unused_indexes（MySQL 5.7+）或information_schema.statistics识别长期未被使用的索引，及时清理
- 注意索引长度限制：UTF8MB4字符集下，VARCHAR(255)字段建索引可能超出单索引767字节限制（InnoDB页内索引键长限制），可指定前缀长度如INDEX idx_name (name(191))
合理规划表结构与读写压力分流
表设计不当会埋下长期隐患，而流量增长后单库单表也难扛住压力：
- 避免大字段（TEXT/BLOB）与热点查询字段混在同一表；高频查询表建议只保留必要字段，大字段单独拆到附表
- 时间字段统一用DATETIME或TIMESTAMP，避免字符串存时间；状态类字段用TINYINT而非VARCHAR，节省空间并加快比较
- 单表数据量超过500万行或容量超2GB时，评估分表（垂直/水平）或归档历史数据
- 读多写少场景，引入主从复制+读写分离，将报表、搜索等查询路由到从库；写压力大时考虑拆分业务库，或使用中间件（如ShardingSphere、MyCat）做分库分表
