学习过程中遇到的问题
一、InnoDB引擎的存储过程存储机制
存储过程的物理存储
在MySQL中，存储过程的元数据（名称、定义、参数等）存储在系统数据库mysql的proc表中，而InnoDB引擎本身并不直接存储存储过程的内容。当存储过程被调用时，MySQL服务器会解析并执行其逻辑，与存储引擎无关。
执行与缓存
- 编译与缓存：存储过程首次执行时会被编译，生成执行计划并缓存，后续调用直接使用缓存版本。
- 事务支持：在InnoDB中，存储过程内的SQL操作遵循事务的ACID特性，可通过
BEGIN、COMMIT、ROLLBACK控制事务。
示例
DELIMITER //
CREATE PROCEDURE GetUser(IN uid INT)
BEGIN
SELECT * FROM users WHERE id = uid;
END //
DELIMITER ;
二、DISTINCT vs GROUP BY：去重的艺术
核心区别
| 特性 | DISTINCT | GROUP BY |
|---|---|---|
| 使用场景 | 简单列去重 | 分组聚合（如COUNT/SUM） |
| 性能 | 单列去重效率高 | 结合聚合函数时更高效 |
| 索引利用 | 依赖单列索引 | 可利用复合索引 |
最佳实践
- 简单去重：优先使用
SELECT DISTINCT column - 复杂场景：需要聚合计算时用
GROUP BY column - 索引优化：两者均可利用索引，但
GROUP BY支持更复杂的索引策略。
三、慢查询监控：SQL性能的照妖镜
配置慢查询日志
-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
-- 设置阈值（单位：秒）
SET GLOBAL long_query_time = 2;
-- 记录未使用索引的查询
SET GLOBAL log_queries_not_using_indexes = 'ON';分析工具
- mysqldumpslow：MySQL自带工具，统计慢查询模式。bash
mysqldumpslow -s t /var/log/mysql-slow.log - pt-query-digest：生成详细分析报告。bash
pt-query-digest /var/log/mysql-slow.log
优化建议
- 使用
EXPLAIN分析执行计划 - 避免全表扫描，优化WHERE条件
- 拆分大查询，分批处理数据
四、索引数量的黄金法则：为什么不超过8-9个？
过多索引的代价
- 写性能下降：每次INSERT/UPDATE/DELETE需更新所有相关索引。
- 存储开销：每个索引占用独立空间（约表数据的20-30%）。
- 优化器负担：索引过多可能导致优化器选择低效执行计划。
优化策略
- 复合索引：将高频查询条件组合成复合索引（如
INDEX (col1, col2)） - 覆盖索引：包含查询所需全部字段，避免回表。
- 定期清理：使用
SHOW INDEX FROM table分析使用频率，删除冗余索引。
五、MySQL主从复制：数据一致性保障
主从复制流程
- 主库：通过Binlog Dump线程发送二进制日志（binlog）。
- 从库：
- I/O线程：接收binlog并写入中继日志（relay log）
- SQL线程：执行relay log中的SQL事件
一致性保障方案
| 方案 | 原理 | 特点 |
|---|---|---|
| 半同步复制 | 主库等待至少一个从库确认写入 | 降低数据丢失风险 |
| GTID（全局事务标识） | 唯一标识事务，自动定位复制位置 | 避免主从数据偏移 |
| 定期校验 | 使用pt-table-checksum检查数据一致性 | 需人工介入修复 |
数据修复手段
bash
# 检查数据一致性
pt-table-checksum --host=主库IP --user=user --password=pass
# 自动修复差异
pt-table-sync --execute --host=主库IP --user=user --password=pass
总结
理解InnoDB存储过程机制、合理选择去重方式、监控慢查询、控制索引数量、保障主从一致性，是构建高性能MySQL系统的关键。建议结合监控工具（如Prometheus+Percona插件）实时跟踪数据库状态，并定期进行全量备份与压力测试，以确保系统的稳定性和可靠性。