From a4c4eb2029e6394c0517146b177119a9259a184a Mon Sep 17 00:00:00 2001 From: Kisa-Dong <84782008+Kisa-Dong@users.noreply.github.com> Date: Thu, 24 Oct 2024 16:29:00 +0800 Subject: [PATCH] =?UTF-8?q?Update=2002.MySQL=E5=B7=A5=E4=BD=9C=E6=B5=81.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 更正文字错误 --- .../02.Mysql/02.MySQL\345\267\245\344\275\234\346\265\201.md" | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git "a/docs/12.\346\225\260\346\215\256\345\272\223/03.\345\205\263\347\263\273\345\236\213\346\225\260\346\215\256\345\272\223/02.Mysql/02.MySQL\345\267\245\344\275\234\346\265\201.md" "b/docs/12.\346\225\260\346\215\256\345\272\223/03.\345\205\263\347\263\273\345\236\213\346\225\260\346\215\256\345\272\223/02.Mysql/02.MySQL\345\267\245\344\275\234\346\265\201.md" index 05d9f88a..48567349 100644 --- "a/docs/12.\346\225\260\346\215\256\345\272\223/03.\345\205\263\347\263\273\345\236\213\346\225\260\346\215\256\345\272\223/02.Mysql/02.MySQL\345\267\245\344\275\234\346\265\201.md" +++ "b/docs/12.\346\225\260\346\215\256\345\272\223/03.\345\205\263\347\263\273\345\236\213\346\225\260\346\215\256\345\272\223/02.Mysql/02.MySQL\345\267\245\344\275\234\346\265\201.md" @@ -105,7 +105,7 @@ mysql> show status like 'last_query_cost'; 示例中的结果表示优化器认为大概需要做 6391 个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的，这些统计信息包括：每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的分布情况等等。 -有非常多的原因会导致 MySQL 选择错误的执行计划，比如统计信息不准确、不会考虑不受其控制的操作成本（用户自定义函数、存储过程）、MySQL 认为的最优跟我们想的不一样（我们希望执行时间尽可能短，但 MySQL 值选择它认为成本小的，但成本小并不意味着执行时间短）等等。 +有非常多的原因会导致 MySQL 选择错误的执行计划，比如统计信息不准确、不会考虑不受其控制的操作成本（用户自定义函数、存储过程）、MySQL 认为的最优跟我们想的不一样（我们希望执行时间尽可能短，但 MySQL 只选择它认为成本小的，但成本小并不意味着执行时间短）等等。 MySQL 的查询优化器是一个非常复杂的部件，它使用了非常多的优化策略来生成一个最优的执行计划： @@ -190,4 +190,4 @@ redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶 ## 参考资料 - [《高性能 MySQL》](https://book.douban.com/subject/23008813/) -- [MySQL 实战 45 讲](https://time.geekbang.org/column/intro/139) \ No newline at end of file +- [MySQL 实战 45 讲](https://time.geekbang.org/column/intro/139)