MySQL 全表扫描

Posted 2023-03-31 cpuCode

mysql 全表扫描

• Server
• • 状态
• InnoDB
• • LRU

Server

将 200G 的 InnoDB 表 db1. t 全表结果保存在客户端 :

mysql -h$host -P$port -u$user -p$pwd -e "select * from db1.t" > $target_file

取/发数据的流程 :

1. 取每一行，写到 net_buffer 中。该内存大小由 net_buffer_length 控制 ，默认: 16k
2. 直到 net_buffer 写满，调用网络接口发出去
3. 当发送成功，就清空 net_buffer，并继续步骤1，2
4. 当返回 EAGAIN 或 WSAEWOULDBLOCK : 本地网络栈（socket send buffer）写满，并等待。直到网络栈重新可写，再继续发送

• socket send buffer (默认定义 /proc/sys/net/core/wmem_default )

查看状态

• State : Sending to client : 服务器端的网络栈写满

show processlist;

解决方法 ：

• 优化查询
• 增大 net_buffer_length

状态

查询语句的状态变化 ：

1. MySQL 查询语句进入执行阶段后，先把状态设置成 Sending data
2. 再发送执行结果的列相关的信息 (meta data) 给客户端
3. 再继续执行语句的流程
4. 执行完成后，把状态设置成空字符串

• Sending data 可能在执行器过程中的任意阶段

锁等待场景 ：

session A	session B
begin;
select * from t where id = 1 for udpate;
	select * from t lock in share mode; (blocked)

读全表被锁 :

show processlist;

• 等锁状态 , 却显示 Sending data
• Sending to client : 当一个线程处于等待客户端接收结果的状态
• Sending data : 只是正在执行

InnoDB

WAL 里 Buffer Pool 配合 redo log，就避免了随机写盘 , 加速更新

• Buffer Pool 还能加速查询

查看 Buffer Pool 命中率 :

show engine innodb status;

稳定的线上服务，内存命中率要在 99% 上 :

控制 InnoDB Buffer Pool 大小 ：

• 一般设置 : 可用物理内存的 60%~80%

innodb_buffer_pool_size

InnoDB 内存管理 : 最近最少使用 (Least Recently Used, LRU) 算法

• 核心 : 淘汰最久未使用的数据

LRU

基本 LRU 算法 :

• state 1 : 链表头部是 P1 : 最近刚刚被访问过的数据页
• state 2 : 当有读请求访问 P3，P3 移到最前面
• state 3 : 当访问数据不在链表中，就新申请个数据页 Px，加到链表头部。但由于内存已经满了，就淘汰链表末尾 Pm
• 缺点 : 当扫描大量历史数据 , 会淘汰 Buffer Pool 中的所有数据 , 那内存命中率会急剧下降，影响性能

改进的 LRU 算法 :

• 按 5:3 比例把 LRU 分为 young 和 old

1. state 1 : 访问数据页 P3，由于 P3 在 young 区，将移到链表头部，变成 state 2
2. state 3 : 当访问数据不在链表中，就淘汰 Pm，把新申请的 Px 放在 LRU_old 处
3. 当 old 区的数据页，每次访问就判断：
   1. 当该数据页在 LRU 中存在时间 > 1 秒，就移到链表头部
   2. 当该数据页在 LRU 中存在时间 < 1 秒，位置保持不变

• 存在时间阈值 (默认 : 1000 ms ) : innodb_old_blocks_time

MySQL视图是不是总是进行全表扫描？

【中文标题】MySQL视图是不是总是进行全表扫描？

【英文标题】：Does MySQL view always do full table scan?MySQL视图是否总是进行全表扫描？

【发布时间】：2010-10-12 20:19:41

【问题描述】：

我正在尝试优化在 MySQL 5.1 中使用视图的查询。似乎即使我从视图中选择 1 列，它也总是会进行全表扫描。这是预期的行为吗？

对于我在下面第一个查询中指定的表，该视图只是一个 SELECT "All Columns From These Tables - NOT *"。

这是我从构成视图的查询中选择索引列 PromotionID 时的解释输出。如您所见，它与视图上的输出有很大不同。

EXPLAIN SELECT pb.PromotionID FROM PromotionBase pb INNER JOIN PromotionCart pct ON pb.PromotionID = pct.PromotionID INNER JOIN PromotionCode pc ON pb.PromotionID = pc.PromotionID WHERE pc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pc
         type: const
possible_keys: PRIMARY,fk_pc_pb
          key: PRIMARY
      key_len: 302
          ref: const
         rows: 1
        Extra:
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: pb
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using index
*************************** 3. row ***************************
           id: 1
  select_type: SIMPLE
        table: pct
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using index
3 rows in set (0.00 sec)

当我从视图中选择相同的东西时的输出

EXPLAIN SELECT vpc.PromotionID FROM vw_PromotionCode vpc  WHERE vpc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 5830
        Extra: Using where
*************************** 2. row ***************************
           id: 2
  select_type: DERIVED
        table: pcart
         type: index
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 33
        Extra: Using index
*************************** 3. row ***************************
           id: 2
  select_type: DERIVED
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.pcart.PromotionID
         rows: 1
        Extra:
*************************** 4. row ***************************
           id: 2
  select_type: DERIVED
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 5. row ***************************
           id: 3
  select_type: UNION
        table: pp
         type: index
possible_keys: PRIMARY
          key: pp_p
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 6. row ***************************
           id: 3
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.pp.PromotionID
         rows: 1
        Extra:
*************************** 7. row ***************************
           id: 3
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 8. row ***************************
           id: 4
  select_type: UNION
        table: pcp
         type: index
possible_keys: PRIMARY
          key: pcp_cp
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 9. row ***************************
           id: 4
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.pcp.PromotionID
         rows: 1
        Extra:
*************************** 10. row ***************************
           id: 4
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 11. row ***************************
           id: 5
  select_type: UNION
        table: ppc
         type: index
possible_keys: PRIMARY
          key: ppc_pc
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 12. row ***************************
           id: 5
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.ppc.PromotionID
         rows: 1
        Extra:
*************************** 13. row ***************************
           id: 5
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 14. row ***************************
           id: 6
  select_type: UNION
        table: ppt
         type: index
possible_keys: PRIMARY
          key: ppt_pt
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 15. row ***************************
           id: 6
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.ppt.PromotionID
         rows: 1
        Extra:
*************************** 16. row ***************************
           id: 6
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 17. row ***************************
           id: NULL
  select_type: UNION RESULT
        table: <union2,3,4,5,6>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
        Extra:
17 rows in set (0.18 sec)

【参考方案1】：

MySQL 中的视图没有索引，因此从本质上讲，每次访问它们时都需要进行完整扫描。一般来说，这使得 Views 仅适用于您有一个相当复杂的静态查询并返回一个小结果集并且您计划每次都获取整个结果集的情况。

编辑： 当然，视图将使用基础表上的索引，以便优化视图本身（否则它们根本没有任何使用意义）但是因为没有索引在视图上，不可能优化视图上的 WHERE 查询。

无论如何，为视图构建索引会很昂贵，因为虽然我没有尝试分析任何视图，但我相当肯定临时表是在幕后构建的，然后返回结果集。构建临时表已经花费了大量时间，我不想要一个也试图猜测需要哪些索引的视图。这就引出了第二点，即 MySQL 目前没有提供一种方法来指定视图使用哪些索引，那么它如何知道需要索引哪些字段？它会根据您的查询猜测吗？

您可以考虑使用Temporary Table，因为这样您就可以在临时表中的字段上指定索引。但是，根据经验，这往往非常非常缓慢。

如果这个视图只包含一个 SELECT ALL FROM table1, table2, table3;那么我不得不问为什么这个查询需要在视图中？如果出于某种原因绝对有必要，您可能希望使用存储过程来封装查询，因为这样您将能够获得优化的性能，同时保持对结果集的数据库调用更简单的好处。

【讨论】：

这里dev.mysql.com/doc/refman/5.0/en/view-restrictions.html 说视图将使用基础表的索引。

我很确定你是对的——对 MySQL 视图的查询可以使用来自其源表的索引。您只是不能在视图本身上有索引，因此不能有一个索引包含来自多个表中的列。

不幸的是，这并不能解释为什么第二个查询被 MySQL 优化得如此糟糕。我所能想到的可能是这种观点并没有完全按照它的意图加入。不过不知道。

如果您在 View 上使用 WHERE 语句，则必须执行全表扫描以查找与 WHERE 子句匹配的值，因为 View 本身没有被索引。

【参考方案2】：

我已经深入研究了它，我错过了一个关键信息点 :( 我的视图查询实际上与另一个表有一个联合。这导致视图使用 TEMPORARY TABLE 算法而不是 MERGE 算法。

TEMPORARY TABLE 算法不允许在基础表中使用索引。

这似乎是 MySQL 中的一个错误，早在 2006 年就已报告，但看起来它在 2009 年并未解决！ http://forums.mysql.com/read.php?100,56681,56681

看起来我只需要将查询重写为外部连接。