亚星游戏性能调优实录，数据库索引优化让查询速度狂飙100倍！
在当今竞争激烈的游戏行业,用户体验就是生命线，对于“亚星游戏”这样拥有海量活跃用户的大型在线游戏而言，系统的响应速度直接决定了玩家的留存率，我们在对亚星游戏的核心数据库进行性能诊断时，发现了一个严重的瓶颈：部分关键业务查询的响应时间竟然高达数秒，严重拖累了系统性能。
经过深入分析与精准优化,我们通过数据库索引策略的调整，成功将核心查询速度提升了100倍！以下是本次优化的全过程复盘。
痛点发现：从“秒开”到“卡顿”
随着亚星游戏用户量的激增,游戏日志表与玩家背包记录表的数据量迅速突破了千万级大关，运营团队反馈，在后台查询玩家高等级装备获取记录以及实时战报时，系统经常出现超时现象。
我们通过慢查询日志分析,定位到了一条罪魁祸首的SQL语句，这条语句旨在查询特定时间段内、特定服务器的玩家充值记录，涉及多表关联和复杂的筛选条件。
优化前的执行情况：
- 扫描行数： 全表扫描，每次查询需读取 500万+ 行数据。
- 响应时间： 平均 3.5秒，高峰期甚至超过 8秒。
- CPU负载： 数据库服务器 CPU 飙升至 90% 以上。
深入诊断：为何查询如此之慢？
使用 EXPLAIN 命令分析该 SQL 的执行计划，我们发现了一个致命问题：索引缺失与索引失效。
- 全表扫描（ALL）： 查询没有命中有效的索引，MySQL 不得不逐行扫描整张表，就像在没有目录的百科全书中查找一个词条，效率极低。
- 字段类型不匹配： 查询条件中的字段类型与表定义不一致，导致隐式类型转换，使得原本可能存在的索引无法被使用。
- 最左前缀原则未遵守： 现有的联合索引（A, B, C）在查询时直接跳过了 A 字段，只使用了 B 字段，导致索引直接失效。
优化实战：构建“高速公路”
针对上述问题,我们制定了针对性的索引优化方案。
建立精准的联合索引
我们分析了业务查询模式,发现绝大多数查询都包含 server_id（服务器ID）、player_id（玩家ID）和 create_time（创建时间）这三个字段。
我们删除了冗余的单列索引，新建了一个联合索引：
ALTER TABLE `game_logs` ADD INDEX `idx_server_player_time` (`server_id`, `player_id`, `create_time`);
设计思路： 利用最左前缀原则，将区分度最高的字段（如 server_id）放在最左边，这样既能满足精确查询，也能支持范围查询。
利用覆盖索引避免回表
原本的查询需要 SELECT *，这意味着即使通过索引找到了行位置，还需要回到原数据表去读取其他列的数据（回表），产生大量的随机 I/O。
我们将业务中不需要的列剔除,只选择必要的字段，或者将被查询的字段全部包含在联合索引中，这样，查询直接从索引树中就能获取所有数据，无需回表，极大地减少了 I/O 操作。
优化查询语句
我们将 SQL 中的 WHERE SUBSTR(player_id, 1, 5) = '10001' 修改为 WHERE player_id LIKE '10001%'。切记：不要在索引列上做函数运算，这会让索引失效，修改后，索引能够重新生效。
成果验证：100倍的性能飞跃
在实施上述优化并重启服务后,我们再次对同一条 SQL 进行压力测试，结果令人振奋：
- 扫描行数： 从 500万+ 行降低至 200行 以内。
- 响应时间： 从 3500ms 缩短至 35ms！
- 性能提升： 查询速度提升100倍！
- 资源占用： 数据库 CPU 使用率大幅下降，系统吞吐量