记一次大库大表的治理过程
内容提要
该文章讨论了MySQL数据库的治理问题，包括降低磁盘使用率、降低主库QPS和消除慢SQL。介绍了大表数据结转、拦截无参数查询、查询切从库和慢SQL治理等治理方案。讨论了分库分表和迁云作为可能的治理方案。
延伸解读
治理背景与硬件风险
该数据库为一主两从架构，均使用零售物理机且已过保，其中一个从库内存减半且磁盘为机械盘，IO性能低，故障风险高。磁盘使用率主库达69%，从库达71%，且周增长量约9-14G，预计可用天数有限。这些硬件隐患在大促前必须解决，否则可能影响业务稳定性。
数据结转策略与效果
针对7张百G以上大表，根据业务属性采用不同结转方式：无历史意义的数据直接删除，纯历史数据同步大数据平台后删除，业务主数据则同步并结转至历史库。通过集中删除和结转，保留365天数据，成功释放470G磁盘空间，降低约10%占用，有效缓解磁盘压力。
无参数查询拦截机制
运单主档查询偶发无参数调用，引发全表扫描和严重慢SQL，导致磁盘繁忙。由于入口众多，在DAO层通过MyBatis插件拦截无参数查询，直接拒绝并告警。上线后此类慢SQL完全消失，避免了因无参查询导致的磁盘繁忙，提升了系统稳定性。
查询切从库与慢SQL治理
通过JSF filter统计接口调用量，识别TOP10查询接口，将其中大部分读查询切换至从库，主库QPS峰值从25k降至17.5k，降低30%。慢SQL治理后，10s以上完全消除，5s以上消除80%，1s以上消除60%。治理过程强调灰度验证，确保稳定。
Q&A
MySQL数据库治理的主要目标是什么？
主要目标是降低磁盘使用率、降低主库QPS和消除慢SQL。
如何降低MySQL数据库的磁盘使用率？
通过数据结转和删除数据来降低磁盘使用率，成功降低了470G的占用。
治理过程中如何处理慢SQL查询？
通过设定针对性的治理措施，成功消除了10s以上的慢SQL，5s以上消除80%。
为什么需要将部分查询切换到从库？
因为主库的QPS远高于从库，切换可以降低主库的负担，保障系统稳定性。
治理方案中提到的拦截无参数查询的作用是什么？
拦截无参数查询可以避免因无参查询导致的慢SQL，从而降低磁盘繁忙度。
未来可能的治理方案有哪些？
未来可能的治理方案包括分库分表和迁云，但需谨慎评估风险和成本。
