在ORACLE 中,我们常常推荐使用exists 来替代in,往往也能取得比较好的优化效果。在ORACLE应用迁往MYSQL的过程中，我们发现部分in 的子查询语句带到MYSQL中，其执行效率变得非常低下，这很让人觉得匪夷所思。于是，我分析了一波。对两个表，分别是一大一小进行关联查询:
开启profile，发现无论是子查询是大表还是小表 ，exists的语句总是比in执行慢：而查看exists语句的profile内容，发现其存在多个executing 和sending data过程，这是整个sql执行的主要耗时过程：而在in 子查询中，sending data这个过程只有一次，这也是整个sql执行主要耗时地方：关于sending data和executing 解析：
Sending data
The thread is reading and processing rows for a SELECT statement, and sending data to the client. Bec开发云主机域名ause operations occurring during this state tend to perform large amounts of disk access (reads), it is often the longest-running state over the lifetime of a given query.
说Sending data 是：线程正在为一个select语句读取和处理行，并且发送数据到客户端。因为这期间操作倾向于大量的磁盘访问（读取），所以这常是整个查询周期中运行时间最长的阶段。（这是MySQL 5.5的解释，5.7的解释完全一样，但是5.7多了一个Sending to client状态）
这样就清楚了，Sending data 做了 读取，处理（过滤，排序等。。）和发送 三件事情，接下来再看该状态下的cpu 和 io 信息 以分析语句的瓶颈是 读取还是处理 ，再做相应的优化调整。。
executing
The thread has begun executing a statement.在exists语句中不断地executing和Sending data 应该是在不断地扫描抓取数据进行匹配，那这应该与MYSQL 的算法有关，通过trace查看其实是在多次子查询 join_execution：想知道这是鸡肋吗，不知有没有相关的解析？
在MySQL的表结构设计中，突然想起来几个地方碰到的问题比较多，大体来说一个就是字符集，一个就是数据类型。 而字符集和数据类型结合起来，就有一个蛮有意思的细节，那就是行长度的问题。 比如我们创建一个表使用了varchar的类型，如果指定为gbk，表里含有一个字…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
