这篇文章主要介绍执行一句SQL的情况有哪些，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
零、数据库驱动
一、数据库连接池
二、SQL 接口
三、查询解析器
四、MySQL 查询优化器
MySQL 会依据成本最小原则来选择使用对应的索引
成本 = IO 成本 + CPU 成本
IO成本 ： 即从磁盘把数据加载到内存的成本，默认情况下，读取数据页的 IO 成本是 1，MySQL 是以页的形式读取数据的，即当用到某个数据时，并不会只读取这个数据，而会把这个数据相邻的数据也一起读到内存中，这就是有名的程序局部性原理，所以 MySQL 每次会读取一整页，一页的成本就是 1。所以 IO 的成本主要和页的大小有关
CPU 成本：将数据读入内存后，还要检测数据是否满足条件和排序等 CPU 操作的成本，显然它与行数有关，默认情况下，检测记录的成本是 0.2。
MySQL 优化器 会计算 「IO 成本 + CPU」 成本最小的那个索引来执行
五、存储引擎
六、执行器
七、Buffer Pool
八、三个日志文件
1、undo 日志文件：记录数据被修改前的样子
2、redo 日志文件：记录数据被修改后的样子
3、bin log 日志文件： 记录整个操作过程
| 性质 | redo Log | bin Log |
|---|
| 文件大小 | redo log 的大小是固定的（配置中也可以设置，一般默认的就足够了） | bin log 可通过配置参数max_bin log_size设置每个bin log文件的大小（但是一般不建议修改）。 |
| 实现方式 | redo log是InnoDB引擎层实现的（也就是说是 Innodb 存储引起过独有的） | bin log是 MySQL 层实现的，所有引擎都可以使用 bin log日志 |
| 记录方式 | redo log 采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。 | bin log 通过追加的方式记录，当文件大小大于给定值后，后续的日志会记录到新的文件上 |
| 使用场景 | redo log适用于崩溃恢复(crash-safe)（这一点其实非常类似与 Redis 的持久化特征） | bin log适用于主从复制和数据恢复 |
bin log 记录的是整个操作记录（这个对于主从复制具有非常重要的意义）
以上是“执行一句SQL的情况有哪些”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注天达云行业资讯频道！