mirror of
https://github.com/zhwei820/learn.lianglianglee.com.git
synced 2025-09-26 05:06:42 +08:00
477 lines
32 KiB
HTML
477 lines
32 KiB
HTML
<!DOCTYPE html>
|
||
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
|
||
<link rel="icon" href="/static/favicon.png">
|
||
<title>18 为什么这些SQL语句逻辑相同，性能却差异巨大？.md.html</title>
|
||
<!-- Spectre.css framework -->
|
||
<link rel="stylesheet" href="/static/index.css">
|
||
<!-- theme css & js -->
|
||
<meta name="generator" content="Hexo 4.2.0">
|
||
</head>
|
||
<body>
|
||
<div class="book-container">
|
||
<div class="book-sidebar">
|
||
<div class="book-brand">
|
||
<a href="/">
|
||
<img src="/static/favicon.png">
|
||
<span>技术文章摘抄</span>
|
||
</a>
|
||
</div>
|
||
<div class="book-menu uncollapsible">
|
||
<ul class="uncollapsible">
|
||
<li><a href="/" class="current-tab">首页</a></li>
|
||
</ul>
|
||
<ul class="uncollapsible">
|
||
<li><a href="../">上一级</a></li>
|
||
</ul>
|
||
<ul class="uncollapsible">
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/00 开篇词 这一次，让我们一起来搞懂MySQL.md.html">00 开篇词 这一次，让我们一起来搞懂MySQL</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/01 基础架构：一条SQL查询语句是如何执行的？.md.html">01 基础架构：一条SQL查询语句是如何执行的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/02 日志系统：一条SQL更新语句是如何执行的？.md.html">02 日志系统：一条SQL更新语句是如何执行的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/03 事务隔离：为什么你改了我还看不见？.md.html">03 事务隔离：为什么你改了我还看不见？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/04 深入浅出索引（上）.md.html">04 深入浅出索引（上）</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/05 深入浅出索引（下）.md.html">05 深入浅出索引（下）</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/06 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？.md.html">06 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/07 行锁功过：怎么减少行锁对性能的影响？.md.html">07 行锁功过：怎么减少行锁对性能的影响？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/08 事务到底是隔离的还是不隔离的？.md.html">08 事务到底是隔离的还是不隔离的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/09 普通索引和唯一索引，应该怎么选择？.md.html">09 普通索引和唯一索引，应该怎么选择？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/10 MySQL为什么有时候会选错索引？.md.html">10 MySQL为什么有时候会选错索引？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/11 怎么给字符串字段加索引？.md.html">11 怎么给字符串字段加索引？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/12 为什么我的MySQL会“抖”一下？.md.html">12 为什么我的MySQL会“抖”一下？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/13 为什么表数据删掉一半，表文件大小不变？.md.html">13 为什么表数据删掉一半，表文件大小不变？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/14 count()这么慢，我该怎么办？.md.html">14 count()这么慢，我该怎么办？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/15 答疑文章（一）：日志和索引相关问题.md.html">15 答疑文章（一）：日志和索引相关问题</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/16 “order by”是怎么工作的？.md.html">16 “order by”是怎么工作的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/17 如何正确地显示随机消息？.md.html">17 如何正确地显示随机消息？</a>
|
||
</li>
|
||
<li>
|
||
<a class="current-tab" href="/专栏/MySQL实战45讲/18 为什么这些SQL语句逻辑相同，性能却差异巨大？.md.html">18 为什么这些SQL语句逻辑相同，性能却差异巨大？</a>
|
||
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/19 为什么我只查一行的语句，也执行这么慢？.md.html">19 为什么我只查一行的语句，也执行这么慢？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/20 幻读是什么，幻读有什么问题？.md.html">20 幻读是什么，幻读有什么问题？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/21 为什么我只改一行的语句，锁这么多？.md.html">21 为什么我只改一行的语句，锁这么多？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/22 MySQL有哪些“饮鸩止渴”提高性能的方法？.md.html">22 MySQL有哪些“饮鸩止渴”提高性能的方法？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/23 MySQL是怎么保证数据不丢的？.md.html">23 MySQL是怎么保证数据不丢的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/24 MySQL是怎么保证主备一致的？.md.html">24 MySQL是怎么保证主备一致的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/25 MySQL是怎么保证高可用的？.md.html">25 MySQL是怎么保证高可用的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/26 备库为什么会延迟好几个小时？.md.html">26 备库为什么会延迟好几个小时？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/27 主库出问题了，从库怎么办？.md.html">27 主库出问题了，从库怎么办？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/28 读写分离有哪些坑？.md.html">28 读写分离有哪些坑？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/29 如何判断一个数据库是不是出问题了？.md.html">29 如何判断一个数据库是不是出问题了？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/30 答疑文章（二）：用动态的观点看加锁.md.html">30 答疑文章（二）：用动态的观点看加锁</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/31 误删数据后除了跑路，还能怎么办？.md.html">31 误删数据后除了跑路，还能怎么办？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/32 为什么还有kill不掉的语句？.md.html">32 为什么还有kill不掉的语句？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/33 我查这么多数据，会不会把数据库内存打爆？.md.html">33 我查这么多数据，会不会把数据库内存打爆？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/34 到底可不可以使用join？.md.html">34 到底可不可以使用join？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/35 join语句怎么优化？.md.html">35 join语句怎么优化？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/36 为什么临时表可以重名？.md.html">36 为什么临时表可以重名？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/37 什么时候会使用内部临时表？.md.html">37 什么时候会使用内部临时表？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/38 都说InnoDB好，那还要不要使用Memory引擎？.md.html">38 都说InnoDB好，那还要不要使用Memory引擎？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/39 自增主键为什么不是连续的？.md.html">39 自增主键为什么不是连续的？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/40 insert语句的锁为什么这么多？.md.html">40 insert语句的锁为什么这么多？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/41 怎么最快地复制一张表？.md.html">41 怎么最快地复制一张表？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/42 grant之后要跟着flush privileges吗？.md.html">42 grant之后要跟着flush privileges吗？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/43 要不要使用分区表？.md.html">43 要不要使用分区表？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/44 答疑文章（三）：说一说这些好问题.md.html">44 答疑文章（三）：说一说这些好问题</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/45 自增id用完怎么办？.md.html">45 自增id用完怎么办？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/我的MySQL心路历程.md.html">我的MySQL心路历程</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/MySQL实战45讲/结束语 点线网面，一起构建MySQL知识网络.md.html">结束语 点线网面，一起构建MySQL知识网络</a>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
|
||
<div class="sidebar-toggle-inner"></div>
|
||
</div>
|
||
<script>
|
||
function add_inner() {
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
inner.classList.add('show')
|
||
}
|
||
function remove_inner() {
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
inner.classList.remove('show')
|
||
}
|
||
function sidebar_toggle() {
|
||
let sidebar_toggle = document.querySelector('.sidebar-toggle')
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
let content = document.querySelector('.off-canvas-content')
|
||
if (sidebar_toggle.classList.contains('extend')) { // show
|
||
sidebar_toggle.classList.remove('extend')
|
||
sidebar.classList.remove('hide')
|
||
content.classList.remove('extend')
|
||
} else { // hide
|
||
sidebar_toggle.classList.add('extend')
|
||
sidebar.classList.add('hide')
|
||
content.classList.add('extend')
|
||
}
|
||
}
|
||
function open_sidebar() {
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
sidebar.classList.add('show')
|
||
overlay.classList.add('show')
|
||
}
|
||
function hide_canvas() {
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
sidebar.classList.remove('show')
|
||
overlay.classList.remove('show')
|
||
}
|
||
</script>
|
||
<div class="off-canvas-content">
|
||
<div class="columns">
|
||
<div class="column col-12 col-lg-12">
|
||
<div class="book-navbar">
|
||
<!-- For Responsive Layout -->
|
||
<header class="navbar">
|
||
<section class="navbar-section">
|
||
<a onclick="open_sidebar()">
|
||
<i class="icon icon-menu"></i>
|
||
</a>
|
||
</section>
|
||
</header>
|
||
</div>
|
||
<div class="book-content" style="max-width: 960px; margin: 0 auto;
|
||
overflow-x: auto;
|
||
overflow-y: hidden;">
|
||
<div class="book-post">
|
||
<p id="tip" align="center"></p>
|
||
<div><h1>18 为什么这些SQL语句逻辑相同，性能却差异巨大？</h1>
|
||
<p>在 MySQL 中，有很多看上去逻辑相同，但性能却差异巨大的 SQL 语句。对这些语句使用不当的话，就会不经意间导致整个数据库的压力变大。</p>
|
||
<p>我今天挑选了三个这样的案例和你分享。希望再遇到相似的问题时，你可以做到举一反三、快速解决问题。</p>
|
||
<h1>案例一：条件字段函数操作</h1>
|
||
<p>假设你现在维护了一个交易系统，其中交易记录表 tradelog 包含交易流水号（tradeid）、交易员 id（operator）、交易时间（t_modified）等字段。为了便于描述，我们先忽略其他字段。这个表的建表语句如下：</p>
|
||
<pre><code>mysql> CREATE TABLE `tradelog` (
|
||
`id` int(11) NOT NULL,
|
||
`tradeid` varchar(32) DEFAULT NULL,
|
||
`operator` int(11) DEFAULT NULL,
|
||
`t_modified` datetime DEFAULT NULL,
|
||
PRIMARY KEY (`id`),
|
||
KEY `tradeid` (`tradeid`),
|
||
KEY `t_modified` (`t_modified`)
|
||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
|
||
</code></pre>
|
||
<p>假设，现在已经记录了从 2016 年初到 2018 年底的所有数据，运营部门有一个需求是，要统计发生在所有年份中 7 月份的交易记录总数。这个逻辑看上去并不复杂，你的 SQL 语句可能会这么写：</p>
|
||
<pre><code>mysql> select count(*) from tradelog where month(t_modified)=7;
|
||
</code></pre>
|
||
<p>由于 t_modified 字段上有索引，于是你就很放心地在生产库中执行了这条语句，但却发现执行了特别久，才返回了结果。</p>
|
||
<p>如果你问 DBA 同事为什么会出现这样的情况，他大概会告诉你：如果对字段做了函数计算，就用不上索引了，这是 MySQL 的规定。</p>
|
||
<p>现在你已经学过了 InnoDB 的索引结构了，可以再追问一句为什么？为什么条件是 where t_modified='2018-7-1’的时候可以用上索引，而改成 where month(t_modified)=7 的时候就不行了？</p>
|
||
<p>下面是这个 t_modified 索引的示意图。方框上面的数字就是 month() 函数对应的值。</p>
|
||
<p><img src="assets/3e30d9a5e67f711f5af2e2599e800286.png" alt="img" /></p>
|
||
<p>图 1 t_modified 索引示意图</p>
|
||
<p>如果你的 SQL 语句条件用的是 where t_modified='2018-7-1’的话，引擎就会按照上面绿色箭头的路线，快速定位到 t_modified='2018-7-1’需要的结果。</p>
|
||
<p>实际上，B+ 树提供的这个快速定位能力，来源于同一层兄弟节点的有序性。</p>
|
||
<p>但是，如果计算 month() 函数的话，你会看到传入 7 的时候，在树的第一层就不知道该怎么办了。</p>
|
||
<p>也就是说，<strong>对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。</strong></p>
|
||
<p>需要注意的是，优化器并不是要放弃使用这个索引。</p>
|
||
<p>在这个例子里，放弃了树搜索功能，优化器可以选择遍历主键索引，也可以选择遍历索引 t_modified，优化器对比索引大小后发现，索引 t_modified 更小，遍历这个索引比遍历主键索引来得更快。因此最终还是会选择索引 t_modified。</p>
|
||
<p>接下来，我们使用 explain 命令，查看一下这条 SQL 语句的执行结果。</p>
|
||
<p><img src="assets/27c2f5ff3549b18ba37a28f4919f3655.png" alt="img" /></p>
|
||
<p>图 2 explain 结果</p>
|
||
<p>key="t_modified"表示的是，使用了 t_modified 这个索引；我在测试表数据中插入了 10 万行数据，rows=100335，说明这条语句扫描了整个索引的所有值；Extra 字段的 Using index，表示的是使用了覆盖索引。</p>
|
||
<p>也就是说，由于在 t_modified 字段加了 month() 函数操作，导致了全索引扫描。为了能够用上索引的快速定位能力，我们就要把 SQL 语句改成基于字段本身的范围查询。按照下面这个写法，优化器就能按照我们预期的，用上 t_modified 索引的快速定位能力了。</p>
|
||
<pre><code>mysql> select count(*) from tradelog where
|
||
-> (t_modified >= '2016-7-1' and t_modified<'2016-8-1') or
|
||
-> (t_modified >= '2017-7-1' and t_modified<'2017-8-1') or
|
||
-> (t_modified >= '2018-7-1' and t_modified<'2018-8-1');
|
||
</code></pre>
|
||
<p>当然，如果你的系统上线时间更早，或者后面又插入了之后年份的数据的话，你就需要再把其他年份补齐。</p>
|
||
<p>到这里我给你说明了，由于加了 month() 函数操作，MySQL 无法再使用索引快速定位功能，而只能使用全索引扫描。</p>
|
||
<p>不过优化器在个问题上确实有“偷懒”行为，即使是对于不改变有序性的函数，也不会考虑使用索引。比如，对于 select * from tradelog where id + 1 = 10000 这个 SQL 语句，这个加 1 操作并不会改变有序性，但是 MySQL 优化器还是不能用 id 索引快速定位到 9999 这一行。所以，需要你在写 SQL 语句的时候，手动改写成 where id = 10000 -1 才可以。</p>
|
||
<h1>案例二：隐式类型转换</h1>
|
||
<p>接下来我再跟你说一说，另一个经常让程序员掉坑里的例子。</p>
|
||
<p>我们一起看一下这条 SQL 语句：</p>
|
||
<pre><code>mysql> select * from tradelog where tradeid=110717;
|
||
</code></pre>
|
||
<p>交易编号 tradeid 这个字段上，本来就有索引，但是 explain 的结果却显示，这条语句需要走全表扫描。你可能也发现了，tradeid 的字段类型是 varchar(32)，而输入的参数却是整型，所以需要做类型转换。</p>
|
||
<p>那么，现在这里就有两个问题：</p>
|
||
<ol>
|
||
<li>数据类型转换的规则是什么？</li>
|
||
<li>为什么有数据类型转换，就需要走全索引扫描？</li>
|
||
</ol>
|
||
<p>先来看第一个问题，你可能会说，数据库里面类型这么多，这种数据类型转换规则更多，我记不住，应该怎么办呢？</p>
|
||
<p>这里有一个简单的方法，看 select “10” > 9 的结果：</p>
|
||
<ol>
|
||
<li>如果规则是“将字符串转成数字”，那么就是做数字比较，结果应该是 1；</li>
|
||
<li>如果规则是“将数字转成字符串”，那么就是做字符串比较，结果应该是 0。</li>
|
||
</ol>
|
||
<p>验证结果如图 3 所示。</p>
|
||
<p><img src="assets/2b67fc38f1651e2622fe21d49950b214.png" alt="img" /></p>
|
||
<p>图 3 MySQL 中字符串和数字转换的效果示意图</p>
|
||
<p>从图中可知，select “10” > 9 返回的是 1，所以你就能确认 MySQL 里的转换规则了：在 MySQL 中，字符串和数字做比较的话，是将字符串转换成数字。</p>
|
||
<p>这时，你再看这个全表扫描的语句：</p>
|
||
<pre><code>mysql> select * from tradelog where tradeid=110717;
|
||
</code></pre>
|
||
<p>就知道对于优化器来说，这个语句相当于：</p>
|
||
<pre><code>mysql> select * from tradelog where CAST(tradid AS signed int) = 110717;
|
||
</code></pre>
|
||
<p>也就是说，这条语句触发了我们上面说到的规则：对索引字段做函数操作，优化器会放弃走树搜索功能。</p>
|
||
<p>现在，我留给你一个小问题，id 的类型是 int，如果执行下面这个语句，是否会导致全表扫描呢？</p>
|
||
<pre><code>select * from tradelog where id="83126";
|
||
</code></pre>
|
||
<p>你可以先自己分析一下，再到数据库里面去验证确认。</p>
|
||
<p>接下来，我们再来看一个稍微复杂点的例子。</p>
|
||
<h1>案例三：隐式字符编码转换</h1>
|
||
<p>假设系统里还有另外一个表 trade_detail，用于记录交易的操作细节。为了便于量化分析和复现，我往交易日志表 tradelog 和交易详情表 trade_detail 这两个表里插入一些数据。</p>
|
||
<pre><code>mysql> CREATE TABLE `trade_detail` (
|
||
`id` int(11) NOT NULL,
|
||
`tradeid` varchar(32) DEFAULT NULL,
|
||
`trade_step` int(11) DEFAULT NULL, /* 操作步骤 */
|
||
`step_info` varchar(32) DEFAULT NULL, /* 步骤信息 */
|
||
PRIMARY KEY (`id`),
|
||
KEY `tradeid` (`tradeid`)
|
||
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
|
||
|
||
insert into tradelog values(1, 'aaaaaaaa', 1000, now());
|
||
insert into tradelog values(2, 'aaaaaaab', 1000, now());
|
||
insert into tradelog values(3, 'aaaaaaac', 1000, now());
|
||
|
||
insert into trade_detail values(1, 'aaaaaaaa', 1, 'add');
|
||
insert into trade_detail values(2, 'aaaaaaaa', 2, 'update');
|
||
insert into trade_detail values(3, 'aaaaaaaa', 3, 'commit');
|
||
insert into trade_detail values(4, 'aaaaaaab', 1, 'add');
|
||
insert into trade_detail values(5, 'aaaaaaab', 2, 'update');
|
||
insert into trade_detail values(6, 'aaaaaaab', 3, 'update again');
|
||
insert into trade_detail values(7, 'aaaaaaab', 4, 'commit');
|
||
insert into trade_detail values(8, 'aaaaaaac', 1, 'add');
|
||
insert into trade_detail values(9, 'aaaaaaac', 2, 'update');
|
||
insert into trade_detail values(10, 'aaaaaaac', 3, 'update again');
|
||
insert into trade_detail values(11, 'aaaaaaac', 4, 'commit');
|
||
</code></pre>
|
||
<p>这时候，如果要查询 id=2 的交易的所有操作步骤信息，SQL 语句可以这么写：</p>
|
||
<pre><code>mysql> select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2; /* 语句 Q1*/
|
||
</code></pre>
|
||
<p>图 4 语句 Q1 的 explain 结果</p>
|
||
<p>我们一起来看下这个结果：</p>
|
||
<ol>
|
||
<li>第一行显示优化器会先在交易记录表 tradelog 上查到 id=2 的行，这个步骤用上了主键索引，rows=1 表示只扫描一行；</li>
|
||
<li>第二行 key=NULL，表示没有用上交易详情表 trade_detail 上的 tradeid 索引，进行了全表扫描。</li>
|
||
</ol>
|
||
<p>在这个执行计划里，是从 tradelog 表中取 tradeid 字段，再去 trade_detail 表里查询匹配字段。因此，我们把 tradelog 称为驱动表，把 trade_detail 称为被驱动表，把 tradeid 称为关联字段。</p>
|
||
<p>接下来，我们看下这个 explain 结果表示的执行流程：</p>
|
||
<p><img src="assets/8289c184c8529acea0269a7460dc62a9.png" alt="img" /></p>
|
||
<p>图 5 语句 Q1 的执行过程</p>
|
||
<p>图中：</p>
|
||
<ul>
|
||
<li>第 1 步，是根据 id 在 tradelog 表里找到 L2 这一行；</li>
|
||
<li>第 2 步，是从 L2 中取出 tradeid 字段的值；</li>
|
||
<li>第 3 步，是根据 tradeid 值到 trade_detail 表中查找条件匹配的行。explain 的结果里面第二行的 key=NULL 表示的就是，这个过程是通过遍历主键索引的方式，一个一个地判断 tradeid 的值是否匹配。</li>
|
||
</ul>
|
||
<p>进行到这里，你会发现第 3 步不符合我们的预期。因为表 trade_detail 里 tradeid 字段上是有索引的，我们本来是希望通过使用 tradeid 索引能够快速定位到等值的行。但，这里并没有。</p>
|
||
<p>如果你去问 DBA 同学，他们可能会告诉你，因为这两个表的字符集不同，一个是 utf8，一个是 utf8mb4，所以做表连接查询的时候用不上关联字段的索引。这个回答，也是通常你搜索这个问题时会得到的答案。</p>
|
||
<p>但是你应该再追问一下，为什么字符集不同就用不上索引呢？</p>
|
||
<p>我们说问题是出在执行步骤的第 3 步，如果单独把这一步改成 SQL 语句的话，那就是：</p>
|
||
<pre><code>mysql> select * from trade_detail where tradeid=$L2.tradeid.value;
|
||
</code></pre>
|
||
<p>其中，$L2.tradeid.value 的字符集是 utf8mb4。</p>
|
||
<p>参照前面的两个例子，你肯定就想到了，字符集 utf8mb4 是 utf8 的超集，所以当这两个类型的字符串在做比较的时候，MySQL 内部的操作是，先把 utf8 字符串转成 utf8mb4 字符集，再做比较。</p>
|
||
<blockquote>
|
||
<p>这个设定很好理解，utf8mb4 是 utf8 的超集。类似地，在程序设计语言里面，做自动类型转换的时候，为了避免数据在转换过程中由于截断导致数据错误，也都是“按数据长度增加的方向”进行转换的。</p>
|
||
</blockquote>
|
||
<p>因此， 在执行上面这个语句的时候，需要将被驱动数据表里的字段一个个地转换成 utf8mb4，再跟 L2 做比较。</p>
|
||
<p>也就是说，实际上这个语句等同于下面这个写法：</p>
|
||
<pre><code>select * from trade_detail where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value;
|
||
</code></pre>
|
||
<p>CONVERT() 函数，在这里的意思是把输入的字符串转成 utf8mb4 字符集。</p>
|
||
<p>这就再次触发了我们上面说到的原则：对索引字段做函数操作，优化器会放弃走树搜索功能。</p>
|
||
<p>到这里，你终于明确了，字符集不同只是条件之一，<strong>连接过程中要求在被驱动表的索引字段上加函数操作</strong>，是直接导致对被驱动表做全表扫描的原因。</p>
|
||
<p>作为对比验证，我给你提另外一个需求，“查找 trade_detail 表里 id=4 的操作，对应的操作者是谁”，再来看下这个语句和它的执行计划。</p>
|
||
<pre><code>mysql>select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;
|
||
</code></pre>
|
||
<p><img src="assets/92cb498ceb3557e41700fae53ce9bd11.png" alt="img" /></p>
|
||
<p>图 6 explain 结果</p>
|
||
<p>这个语句里 trade_detail 表成了驱动表，但是 explain 结果的第二行显示，这次的查询操作用上了被驱动表 tradelog 里的索引 (tradeid)，扫描行数是 1。</p>
|
||
<p>这也是两个 tradeid 字段的 join 操作，为什么这次能用上被驱动表的 tradeid 索引呢？我们来分析一下。</p>
|
||
<p>假设驱动表 trade_detail 里 id=4 的行记为 R4，那么在连接的时候（图 5 的第 3 步），被驱动表 tradelog 上执行的就是类似这样的 SQL 语句：</p>
|
||
<pre><code>select operator from tradelog where traideid =$R4.tradeid.value;
|
||
</code></pre>
|
||
<p>这时候 $R4.tradeid.value 的字符集是 utf8, 按照字符集转换规则，要转成 utf8mb4，所以这个过程就被改写成：</p>
|
||
<pre><code>select operator from tradelog where traideid =CONVERT($R4.tradeid.value USING utf8mb4);
|
||
</code></pre>
|
||
<p>你看，这里的 CONVERT 函数是加在输入参数上的，这样就可以用上被驱动表的 traideid 索引。</p>
|
||
<p>理解了原理以后，就可以用来指导操作了。如果要优化语句</p>
|
||
<pre><code>select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2;
|
||
</code></pre>
|
||
<p>的执行过程，有两种做法：</p>
|
||
<ul>
|
||
<li>比较常见的优化方法是，把 trade_detail 表上的 tradeid 字段的字符集也改成 utf8mb4，这样就没有字符集转换的问题了。</li>
|
||
</ul>
|
||
<pre><code>alter table trade_detail modify tradeid varchar(32) CHARACTER SET utf8mb4 default null;
|
||
</code></pre>
|
||
<ul>
|
||
<li>如果能够修改字段的字符集的话，是最好不过了。但如果数据量比较大， 或者业务上暂时不能做这个 DDL 的话，那就只能采用修改 SQL 语句的方法了。</li>
|
||
</ul>
|
||
<pre><code>mysql> select d.* from tradelog l , trade_detail d where d.tradeid=CONVERT(l.tradeid USING utf8) and l.id=2;
|
||
</code></pre>
|
||
<p><img src="assets/aa844a7bf35d330b9ec96fc159331bd6.png" alt="img" /></p>
|
||
<p>图 7 SQL 语句优化后的 explain 结果</p>
|
||
<p>这里，我主动把 l.tradeid 转成 utf8，就避免了被驱动表上的字符编码转换，从 explain 结果可以看到，这次索引走对了。</p>
|
||
<h1>小结</h1>
|
||
<p>今天我给你举了三个例子，其实是在说同一件事儿，即：<strong>对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。</strong></p>
|
||
<p>第二个例子是隐式类型转换，第三个例子是隐式字符编码转换，它们都跟第一个例子一样，因为要求在索引字段上做函数操作而导致了全索引扫描。</p>
|
||
<p>MySQL 的优化器确实有“偷懒”的嫌疑，即使简单地把 where id+1=1000 改写成 where id=1000-1 就能够用上索引快速查找，也不会主动做这个语句重写。</p>
|
||
<p>因此，每次你的业务代码升级时，把可能出现的、新的 SQL 语句 explain 一下，是一个很好的习惯。</p>
|
||
<p>最后，又到了思考题时间。</p>
|
||
<p>今天我留给你的课后问题是，你遇到过别的、类似今天我们提到的性能问题吗？你认为原因是什么，又是怎么解决的呢？</p>
|
||
<p>你可以把你经历和分析写在留言区里，我会在下一篇文章的末尾选取有趣的评论跟大家一起分享和分析。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一起阅读。</p>
|
||
<h1>上期问题时间</h1>
|
||
<p>我在上篇文章的最后，留给你的问题是：我们文章中最后的一个方案是，通过三次 limit Y,1 来得到需要的数据，你觉得有没有进一步的优化方法。</p>
|
||
<p>这里我给出一种方法，取 Y1、Y2 和 Y3 里面最大的一个数，记为 M，最小的一个数记为 N，然后执行下面这条 SQL 语句：</p>
|
||
<pre><code>mysql> select * from t limit N, M-N+1;
|
||
</code></pre>
|
||
<p>再加上取整个表总行数的 C 行，这个方案的扫描行数总共只需要 C+M+1 行。</p>
|
||
</div>
|
||
</div>
|
||
<div>
|
||
<div style="float: left">
|
||
<a href="/专栏/MySQL实战45讲/17 如何正确地显示随机消息？.md.html">上一页</a>
|
||
</div>
|
||
<div style="float: right">
|
||
<a href="/专栏/MySQL实战45讲/19 为什么我只查一行的语句，也执行这么慢？.md.html">下一页</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
|
||
</div>
|
||
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"709972b0e9ae3d60","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
|
||
</body>
|
||
<!-- Global site tag (gtag.js) - Google Analytics -->
|
||
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
|
||
<script>
|
||
window.dataLayer = window.dataLayer || [];
|
||
function gtag() {
|
||
dataLayer.push(arguments);
|
||
}
|
||
gtag('js', new Date());
|
||
gtag('config', 'G-NPSEEVD756');
|
||
var path = window.location.pathname
|
||
var cookie = getCookie("lastPath");
|
||
console.log(path)
|
||
if (path.replace("/", "") === "") {
|
||
if (cookie.replace("/", "") !== "") {
|
||
console.log(cookie)
|
||
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
|
||
}
|
||
} else {
|
||
setCookie("lastPath", path)
|
||
}
|
||
function setCookie(cname, cvalue) {
|
||
var d = new Date();
|
||
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
|
||
var expires = "expires=" + d.toGMTString();
|
||
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
|
||
}
|
||
function getCookie(cname) {
|
||
var name = cname + "=";
|
||
var ca = document.cookie.split(';');
|
||
for (var i = 0; i < ca.length; i++) {
|
||
var c = ca[i].trim();
|
||
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
|
||
}
|
||
return "";
|
||
}
|
||
</script>
|
||
</html>
|