DDR爱好者之家

记一次因线上mysql优化器误判引起慢查询事件
站长资源 2024/11/24 佚名
76 1538
DDR爱好者之家 Design By 杰米

前言:

     收到疯狂的慢查询及请求超时报警，通过metrics分析出来自mysql请求的异常，cli —> show proceslist 看到很多慢查询。 先前该sql是没有的，后面因为数据量的增长才出现了这问题。 虽然feeds表大到一个亿，但因为feeds流信息有近期热的特征，所以不是因为 innodb_buffer_pool_size 低效引起的io频繁。 后来经过进一步explain执行计划分析得出了原因，mysql查询优化器选择了他认为高效的索引。

mysql查询优化器大多数情况是靠谱的!  但是你的sql语言含有多个索引时就要注意了，往往最后的结果令人有些彷徨了。因为mysql同一个sql只能使用一个索引，那么选择哪个呢？ 在数据量小时候，mysql优化器会把主键索引后置，优先使用 index和unique 。 当你达到一个数据量级后，又因为你的查询操作有 in ，那么mysql查询优化器很可能会选用主键的 ！

记住一句话，mysql查询优化是基于检索成本考虑，而不是基于时间成本考虑。 优化器是根据现有的数据状态来推算代价，而不是真的去执行一遍sql.

所以，mysql优化器并不是每次都可以达到优化的效果的。 它并不能准确预估代价，如果要准确得到走各个索引的代价就要去真的执行一遍才能知道，所以代价分析只是做了一个预估，既然是预估那么就有误判。

我们这里说的表是feed信息流表，我们知道feeds信息流表访问不仅频繁，而且数据量也很大。 但是这个表的数据结构很简单，索引也简单.   一共就两个索引，一个是主键索引， 一个是unique唯一键索引。

如下，该表的量级已经到亿级别了，因为有足够多的cache前顶，又因为这样那样的原因，所以没来的及做分库分表。

记一次因线上mysql优化器误判引起慢查询事件

问题是这样的， 当数据量级不到一个亿的时候，mysql优化器选择使用 index索引， 当数据量级超过一个亿后，mysql查询优化器选择使用 主键索引了。  这样带来的问题就是 查询速度太慢。

这是正常情况下:

mysql> explain SELECT * FROM `feed` WHERE user_id IN (116537309,116709093,116709377)     AND cid IN (1001,1005,1054,1092,1093,1095)  AND id <= 128384713 ORDER BY id DESC LIMIT 0, 11 \G;
*************************** 1. row ***************************
      id: 1
 select_type: SIMPLE
    table: feed
  partitions: NULL
     type: range
possible_keys: PRIMARY,feed_user_target
     key: feed_user_target
   key_len: 6
     ref: NULL
     rows: 18
   filtered: 50.00
    Extra: Using where; Using index; Using filesort
1 row in set, 1 warning (0.00 sec)

同样的sql语句，在数据量有较大变化后，mysql查询优化器对索引的选择也有了变化。

mysql> explain SELECT * FROM `feed` WHERE user_id IN (116537309,116709093,116709377)    AND cid IN (1001,1005,1054,1092,1093,1095)    AND id <= 128384713 ORDER BY id DESC LIMIT 0, 11 \G;
*************************** 1. row ***************************
      id: 1
 select_type: SIMPLE
    table: feed
     type: range
possible_keys: PRIMARY,feed_user_target
     key: PRIMARY
   key_len: 4
     ref: NULL
     rows: 11873197
    Extra: Using where
1 row in set (0.00 sec)

那么解决方法是使用 force index，强制查询优化器使用我们给出的index 。 我这里是python开发环境，常见的python orm都有force index，ignore index，user index 参数的。

explain  SELECT * FROM `feed` force index (feed_user_target) WHERE user_id IN (116537309,116709093,116709377) ...

那么我们应该怎么预防这种 因为数据的增进，mysql优化器选择了一个低效索引的问题呢？

针对这个问题请教了几个厂的dba，得到的答案和我们的方法是一样的。 都是只能通过后期的慢查询来发现问题，然后在sql语句中指定force index来解决索引问题。 另外，在系统上线初期就会做这类问题的规避，但往往业务开发人员初期都会配合dba们的审查工作，但后期为了省事，或者说自以为是认为没有问题，所以造成了 mysql查询事故。

我自己对于mysql优化器选择索引规则一知半解的，后面准备花时间好好研究下规则

DDR爱好者之家 Design By 杰米
广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
DDR爱好者之家 Design By 杰米
ddrfans.com DDR爱好者之家
8,675无损音乐
1,324高清电影
213破解软件
70,141收录资讯

《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。

更新日志

友情链接

杰晶网络 DDR爱好者之家 南强小屋 黑松山资源网 白云城资源网
DDR爱好者之家 Design By 杰米