"\u003cp\u003e话说有这么一个表：\u003c/p\u003e\n\u003cp\u003eCREATE TABLE \u003ccode\u003euser_group\u003c/code\u003e (\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eid\u003c/code\u003e int(11) NOT NULL auto_increment,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003euid\u003c/code\u003e int(11) NOT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003egroup_id\u003c/code\u003e int(11) NOT NULL,\u003c/p\u003e\n\u003cp\u003ePRIMARY KEY  (\u003ccode\u003eid\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003eKEY \u003ccode\u003euid\u003c/code\u003e (\u003ccode\u003euid\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003eKEY \u003ccode\u003egroup_id\u003c/code\u003e (\u003ccode\u003egroup_id\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003e) ENGINE=InnoDB AUTO_INCREMENT=750366 DEFAULT CHARSET=utf8\u003c/p\u003e\n\u003cp\u003e看AUTO_INCREMENT就知道数据并不多，75万条。然后是一条简单的查询：\u003c/p\u003e\n\u003cp\u003e　　SELECT SQL_NO_CACHE uid FROM user_group WHERE group_id = 245;\u003c/p\u003e\n\u003cp\u003e很简单对不对?怪异的地方在于：\u003c/p\u003e\n\u003cp\u003e如果换成MyISAM做存储引擎的时候，查询耗时只需要0.01s，用InnoDB却会是0.15s左右。\u003c/p\u003e\n\u003cp\u003e如果只是就这么点差距其实不是什么大不了的事，但是真实的业务需求比这个复杂，造成的差距也很大：MyISAM只需要0.12s，InnoDB则需要2.2s.，最终定位到问题症结是在这 …\u003c/p\u003e"

"\u003cp\u003e今天丁原问我mysql执行计划中的key_len是怎么计算得到的，当时还没有注意，在高性能的那本书讲到过这个值的计算，但是自己看执行计划的时候一直都没有太在意这个值，更不用说深讨这个值的计算了：\u003c/p\u003e\n\u003cp\u003eken_len表示索引使用的字节数，根据这个值，就可以判断索引使用情况，特别是在组合索引的时候，判断所有的索引字段都被查询用到。\u003c/p\u003e\n\u003cp\u003e在查看官方文档的时候，也没有发现详细的key_len的计算介绍，后来做了一些测试，在咨询了丁奇关于变长数据类型的值计算的时候，突然想到innodb 行的格式，在这里的计算中有点类似，总结一下需要考虑到以下一些情况：(1).索引字段的附加信息：可以分为\u003cstrong\u003e变长\u003c/strong\u003e和\u003cstrong\u003e定长\u003c/strong\u003e数据类型讨论\n当索引字段为定长数据类型，比如char，int，datetime，需要有是否为空的标记，这个标记需要占用\u003cstrong\u003e1\u003c/strong\u003e个字节；\n对于变长数据类型，比如：varchar，除了是否为空的标记外，还需要有长度信息，需要占用\u003cstrong\u003e2\u003c/strong\u003e个字节；\u003c/p\u003e\n\u003cp\u003e(备注：当字段定义为非空的时候，是否为空的标记将不占用字节)\u003c/p\u003e\n\u003cp\u003e(2).同时还需要考虑表所使用的字符集，不同的字符集，gbk编码的为一个字符2个字节，utf8编码的一个字符3个字节;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e先 …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eExplain ID详解\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e含义：select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eid的情况有三种，分别是：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eid相同表示加载表的顺序是从上到下。\u003c/li\u003e\n\u003cli\u003eid不同id值越大，优先级越高，越先被执行。\u003c/li\u003e\n\u003cli\u003eid有相同，也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行；在所有的组中，id的值越大，优先级越高，越先执行。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e再看一个查询计划的例子：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://blog.haohtml.com/wp-content/uploads/2010/06/mysql_explain.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql_explain.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e执行顺序依次为 4 -\u0026gt; 3 -\u0026gt; 2 \u0026gt; 1 \u0026gt; NULL\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e第一行：id列为1，表示第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中3代表该查询衍生自第三个select查询，即id为3的select。[select d1.name……]\u003c/p\u003e\n\u003cp\u003e第二行：id为3，表示该查询的执行次序为2（4→3），是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。[select id,name from t1 where other_column=”]\u003c/p\u003e\n\u003cp\u003e第三 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e1.1优化SQL的一般步骤\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e11.1.1\u003c/strong\u003e \u003cstrong\u003e通过show status和应用特点了解各种SQL的执行频率\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e通过SHOW STATUS可以提供服务器状态信息，也可以使用mysqladminextended- status命令获得。SHOW STATUS可以根据需要显示session级别的统计结果和global 级别的统计结果。\u003c/p\u003e\n\u003cp\u003e以下几个参数对Myisam和Innodb存储引擎都计数：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eCom_select 执行select操作的次数，一次查询只累加1；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCom_insert执行insert操作的次数，对于批量插入的insert操作，只累加一次；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCom_update执行update操作的次数；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCom_delete 执行delete操作的次数；\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e以下几个参数是针对Innodb存储引擎计数的，累加的算法也略有不同：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eInnodb_rows_read select查询返回的行数；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eInnodb_rows_inserted执行Insert操作插入的行数；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eInnodb_rows_updated执行update操作更新的行数； …\u003c/p\u003e\u003c/li\u003e\u003c/ol\u003e"

"\u003cp\u003e可以参考一下官方文档中的解释。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/optimization.html\"\u003ehttp://dev.mysql.com/doc/refman/5.1/zh/optimization.html\u003c/a\u003e\u003c/p\u003e\n\u003col start=\"7\"\u003e\n\u003cli\u003e优化\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e7.1. 优化概述\u003c/p\u003e\n\u003cp\u003e7.1.1. MySQL设计局限与折衷\u003c/p\u003e\n\u003cp\u003e7.1.2. 为可移植性设计应用程序\u003c/p\u003e\n\u003cp\u003e7.1.3. 我们已将MySQL用在何处？\u003c/p\u003e\n\u003cp\u003e7.1.4. MySQL基准套件\u003c/p\u003e\n\u003cp\u003e7.1.5. 使用自己的基准\u003c/p\u003e\n\u003cp\u003e7.2. 优化SELECT语句和其它查询\u003c/p\u003e\n\u003cp\u003e7.2.1. EXPLAIN语法（获取SELECT相关信息）\u003c/p\u003e\n\u003cp\u003e7.2.2. 估计查询性能\u003c/p\u003e\n\u003cp\u003e7.2.3. SELECT查询的速度\u003c/p\u003e\n\u003cp\u003e7.2.4. MySQL怎样优化WHERE子句\u003c/p\u003e\n\u003cp\u003e7.2.5. 范围优化\u003c/p\u003e\n\u003cp\u003e7.2.6. 索引合并优化\u003c/p\u003e\n\u003cp\u003e7.2.7. MySQL如何优化IS NULL\u003c/p\u003e\n\u003cp\u003e7.2.8. MySQL如何优化DISTINCT\u003c/p\u003e\n\u003cp\u003e7.2.9. MySQL如何优化LEFT JOIN和RIGHT JOIN\u003c/p\u003e\n\u003cp\u003e7.2.10. MySQL如何优化嵌套Join\u003c/p\u003e\n\u003cp\u003e7.2.11. MySQL如何简化外部联合\u003c/p\u003e\n\u003cp\u003e7.2.12. MySQL如何优化ORDER BY\u003c/p\u003e\n\u003cp\u003e7.2.13. MySQL如何优化GROUP BY …\u003c/p\u003e"

"\u003cp\u003e用EXPLAIN看MySQL的执行计划时经常会看到Impossible WHERE noticed after reading const tables这句话，意思是说MySQL通过读取“const tables”，发现这个查询是不可能有结果输出的。比如对下面的表和数据：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e create table t (a int primary key, b int) engine = innodb;\n insert into t values(1, 1);\n insert into t values(3, 1);\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e执行“EXPLAIN select * from t where a = 2”时就会输出“Impossible WHERE noticed after reading const tables”。\u003c/p\u003e\n\u003cp\u003e不 明白所谓的“const tables”是什么意思，对MySQL在查询优化时竟然可以发现一个查询不可能输出结果更是感觉不可思议。按数据库中“传统”的做法，查询优化时只会访 问模式定义和统计信息，而据我所知，数据库中使用的各种统计信息如EquiDepth、MaxDiff柱状图，MCV， …\u003c/p\u003e"

"\u003cp\u003eExplain虽然是大家常用的分析mysql优化的办法，但对于系统级别内容的消耗资源信息就无能为力了．这时需要用到Mysql中的Profiling(程序剖析) 功能．参考：\u003c/p\u003e\n\u003cp\u003eEXPLAIN tbl_name or EXPLAIN SELECT select_options\u003c/p\u003e\n\u003cp\u003eEXPLAIN tbl_name是DESC[RIBE] tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。\u003c/p\u003e\n\u003cp\u003e当你在一条SELECT语句前放上关键词EXPLAIN，MySQL解释它将如何处理SELECT，提供有关表如何联结和以什么次序联结的信息。\u003c/p\u003e\n\u003cp\u003e借助于EXPLAIN，你可以知道\n1)你什么时候必须为表加入索引以得到一个使用索引找到记录的更快的SELECT。\n2)你也能知道优化器是否以一个最佳次序联结表。为了强制优化器对一个SELECT语句使用一个特定联结次序，增加一个STRAIGHT_JOIN子句。\u003c/p\u003e\n\u003cp\u003e对于非简单的联结，EXPLAIN为用于SELECT语句中的每个表返回一行信息。表以他们将被读入的顺序被列出。\nMySQL用一边扫描多次联结的方式解决所有联结，这意味着MySQL 1)从第 …\u003c/p\u003e"