俄语网站建设注意事项,怎么开网店淘宝,短视频剪辑自学,公司网站建设费用会计处理摘要#xff1a; 第一部分#xff1a;基础知识 第二部分#xff1a;MYISAM和INNODB索引结构 1、简单介绍B-tree B tree树 2、MyisAM索引结构 3、Annode索引结构 4、MyisAM索引与InnoDB索引相比较 第三部分#xff1a;MYSQL优化 1、表数据类型选择 2、sql语句优化 (1) 最…摘要 第一部分基础知识 第二部分MYISAM和INNODB索引结构 1、简单介绍B-tree B tree树 2、MyisAM索引结构 3、Annode索引结构 4、MyisAM索引与InnoDB索引相比较 第三部分MYSQL优化 1、表数据类型选择 2、sql语句优化 (1)     最左前缀原则 (1.1)  能正确的利用索引 (1.2)  不能正确的利用索引 (1.3)  如果一个查询where子句中确实不需要password列那就用“补洞”。 (1.4)  like (2)     Order by 优化 (2.1)filesort优化算法. (2.2)单独order by 用不了索引索引考虑加where 或加limit (2.3)where orerby 类型where满足最左前缀原则且orderby的列和where子句用到的索引的列的子集。即是(a,b,c)索引where满足最左前缀原则且order by中列a、b、c的任意组合 (2.4) where orerbylimit (2.5)如何考虑order by来建索引 (3)     隔离列 (4)     OR、IN、UNION ALL可以尝试用UNION ALL (4.1)or会遍历表就算有索引 (4.2)关于in (4.2)UNION All (5)     范索引选择性 (6)     重复或多余索引 3、系统配置与维护优化 (1)     重要的一些变量 (2)     Fdsoptimize、Analyze、check、repair维护操作 (3)     表结构的更新与维护 第四部分图说mysql查询执行流程       第一部分基础知识 索引 官方介绍索引是帮助MySQL高效获取数据的数据结构。笔者理解索引相当于一本书的目录通过目录就知道要的资料在哪里不用一页一页查阅找出需要的资料。关键字index ------------------------------------------------------------- 唯一索引 强调唯一就是索引值必须唯一关键字unique index 创建索引 1、create unique index 索引名 on 表名(列名); 2、alter table 表名 add unique index 索引名 (列名); 删除索引 1、  drop index 索引名 on 表名; 2、  alter table 表名 drop index 索引名; ------------------------------------------------------------- 主键 主键就是唯一索引的一种主键要求建表时指定一般用auto_increatment列关键字是primary key 主键创建 creat table test2 (id int not null primary key auto_increment); ------------------------------------------------------------- 全文索引 InnoDB不支持Myisam支持性能比较好一般在 CHAR、VARCHAR 或 TEXT 列上创建。 Create table 表名( id int not null primary anto_increment,title varchar(100),FULLTEXT(title))typemyisam ------------------------------ 单列索引与多列索引 索引可以是单列索引也可以是多列索引(也叫复合索引)。按照上面形式创建出来的索引是单列索引现在先看看创建多列索引 create table test3 (id int not null primary key auto_increment,uname char (8) not null default ,password char(12) not null,INDEX(uname,password))type myisam; 注意INDEX(a, b, c)可以当做a或(a, b)的索引来使用但和b、c或(b,c)的索引来使用这是一个最左前缀的优化方法在后面会有详细的介绍你只要知道有这样两个概念 ------------------------------------------------------------- 聚集索引 一种索引该索引中键值的逻辑顺序决定了表中相应行的物理顺序。聚集索引确定表中数据的物理顺序。Mysql中myisam表是没有聚集索引的innodb有(主键就是聚集索引)聚集索引在下面介绍innodb结构的时有详细介绍。 ------------------------------------------------------------- 查看表的索引 通过命令Show index from 表名 如 mysql show index from test3;   ------------------------------------------------------------------------------------------------------ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |   ------------------------------------------------------------------------------------------------------ | test3 |          0 | PRIMARY  |        1  |    id          |     A     |   0          |     NULL | NULL   |     | BTREE      |         |   -------------------------------------------------------------------------------------------------------- Table表名 Key_name什么类型索引(这了是主键) Column_name索引列的字段名 Cardinality索引基数很关键的一个参数平均数值组索引基数/表总数据行平均数值组越接近1就越有可能利用索引 Index_type如果索引是全文索引则是fulltext,这里是btree索引btre也是这篇文章研究的重点之一 其他的就不详细介绍更多 第二部分MYISAM和INNODB索引结构 1、 简单介绍B-tree B tree树 B-tree结构视图 一棵m阶的B-tree树则有以下性质 (1)Ki表示关键字值上图中k1 … 该关键字值右子节点关键字值) (2)Pi表示指向子节点的指针左指针指向左子节点右指针指向右子节点。即是p1[指向值] (3)所有关键字必须唯一值(这也是创建myisam 和innodb表必须要主键的原因)每个节点包含一个说明该节点多少个关键字如上图第二行的i和n (4)节点 l  每个节点最可以有m个子节点。 l  根节点若非叶子节点至少2个子节点最多m个子节点 l  每个非根非叶子节点至少[m/2]子节点或叫子树([]表示向上取整)最多m个子节点 (5)关键字 l  根节点的关键字个数1~m-1 l  非根非叶子节点的关键字个数[m/2]-1~m-1,如m3则该类节点关键字个数2-1~2 (6)关键字数k和指向子节点个数指针p的关系 l  k1p 注意根据储存数据的具体需求左右指针为空时要有标志位表示没有  Btree结构示意图如下   B树是B-树的变体也是一种多路搜索树 l  非叶子结点的子树指针与关键字个数相同 l  为所有叶子结点增加一个链指针(红点标志的箭头)     B树是B-树的变体也是一种多路搜索树 l  非叶子结点的子树指针与关键字个数相同 l  为所有叶子结点增加一个链指针(红点标志的箭头) 2、 MyisAM索引结构 MyisAM索引用的Btree来储存数据MyisAM索引的指针指向的是键值的地址地址存储的是数据如下图 (1)结构讲解上图3阶树主键是Col2Col值就是改行数据保存的物理地址其中红色部分是说明标注。 l  1标注部分也许会迷惑前面不是说关键字15右指针的指向键值要大于15怎么下面还有15关键字因为Btree的所以叶子节点包含所有关键字且是按照升序排列(主键索引唯一辅助索引可以不唯一)所以等于关键字的数据值在右子树 l  2标注是相应关键字存储对应数据的物理地址注意这也是之后和InnoDB索引不同的地方之一 l  2标注也是一个所说MyiAM表的索引和数据是分离的索引保存在”表名.MYI”文件内而数据保存在“表名.MYD”文件内2标注的物理地址就是“表名.MYD”文件内相应数据的物理地址。(InnoDB表的索引文件和数据文件在一起) l  辅助索引和主键索引没什么大的区别辅助索引的索引值是可以重复的(但InnoDB辅助索引和主键索引有很明显的区别这里先提醒注意一下) 3、 Annode索引结构 (1)首先有一个表内容和主键索引结构如下两图 Col1 Col2 Col3 1 15 phpben 2 20 mhycoe 3 23 phpyu 4 25 bearpa 5 40 phpgoo 6 45 phphao 7 48 phpxue …… 结构上由上图可以看出InnoDB的索引结构很MyisAM的有很明显的区别 l  MyisAM表的索引和数据是分开的用指针指向数据的物理地址而InnoDB表中索引和数据是储存在一起。看红框1可一看出一行数据都保存了。 l  还有一个上图多了三行的隐藏数据列(虚线表)这是因为MyisAM不支持事务InnoDB处理事务在性能上并发控制上比较好看图中的红框2中的DB_TRX_ID是事务ID自动增长db_roll_ptr是回滚指针用于事务出错时数据回滚恢复db_row_id是记录行号这个值其实在主键索引中就是主键值这里标出重复是为了容易介绍还有的是若不是主键索引(辅助索引)db_row_id会找表中unique的列作为值若没有unique列则系统自动创建一个。关于InnoDB跟多事务MVCC点此http://www.phpben.com/?post72 (2)加入上表中Col1是主键(下图标错)而Col2是辅助索引则相应的辅助索引结构图   可以看出InnoDB辅助索引并没有保存相应的所有列数据而是保存了主键的键值(图中1、2、3….)这样做利弊也是很明显 l  在已有主键索引避免数据冗余同时在修改数据的时候只需修改辅助索引值。 l  但辅助索引查找数据事要检索两次先找到相应的主键索引值然后在去检索主键索引找到对应的数据。这也是网上很多mysql性能优化时提到的“主键尽可能简短”的原因主键越长辅助索引也就越大当然主键索引也越大。 4、 MyisAM索引与InnoDB索引相比较 l MyisAM支持全文索引(FULLTEXT)、压缩索引InnoDB不支持 l AnnoDB支持事务MyisAM不支持 l MyisAM顺序储存数据索引叶子节点保存对应数据行地址辅助索引很主键索引相差无几AnnoDB主键节点同时保存数据行其他辅助索引保存的是主键索引的值 l MyisAM键值分离索引载入内存(key_buffer_size),数据缓存依赖操作系统InnoDB键值一起保存索引与数据一起载入InnoDB缓冲池 l MyisAM主键(唯一)索引按升序来存储存储InnoDB则不一定 l MyisAM索引的基数值(Cardinalityshow index 命令可以看见)是精确的InnoDB则是估计值。这里涉及到信息统计的知识MyisAM统计信息是保存磁盘中在alter表或Analyze table操作更新此信息而InnoDB则是在表第一次打开的时候估计值保存在缓存区内 l MyisAM处理字符串索引时用增量保存的方式如第一个索引是‘preform’第二个是‘preformence’则第二个保存是‘7ance‘这个明显的好处是缩短索引但是缺陷就是不支持倒序提取索引必须顺序遍历获取索引     第三部分MYSQL优化 mysql优化是一个重大课题之一这里会重点详细的介绍mysql优化包括表数据类型选择sql语句优化系统配置与维护优化三类。 1、  表数据类型选择 (1)能小就用小。表数据类型第一个原则是使用能正确的表示和存储数据的最短类型。这样可以减少对磁盘空间、内存、cpu缓存的使用。 (2)避免用NULL这个也是网上优化技术博文传的最多的一个。理由是额外增加字节还有使索引索引统计和值更复杂。很多还忽略一     个count(列)的问题count(列)是不会统计列值为null的行数。更多关于NULL可参考http://www.phpben.com/?post71 (3)字符串如何选择char和varchar一般phper能想到就是char是固定大小varchar能动态储存数据。这里整理一下这两者的区别 属性 Char Varchar 值域大小 最长字符数是255(不是字节)不管什么编码超过此值则自动截取255个字符保存并没有报错。 65535个字节开始两位存储长度超过255个字符用2位储存长度否则1位具体字符长度根据编码来确定如utf8 则字符最长是21845个 如何处理字符串末尾空格 去掉末尾空格取值出来比较的时候自动加上进行比较 Version4.1字符串末尾空格被删掉version5.0则保留 储存空间 固定空间比喻char(10)不管字符串是否有10个字符都分配10个字符的空间 Varchar内节约空间但更新可能发生变化若varchar(10),开始若储存5个字符当update成7个时有myisam可能把行拆开innodb可能分页这样开销就增大 适用场合 适用于存储很短或固定或长度相似字符如MD5加密的密码char(33)、昵称char(8)等 当最大长度远大于平均长度并且发生更新的时候。   注意当一些英文或数据的时候最好用每个字符用字节少的类型如latin1 (4)整型、整形优先原则 Tinyint、smallint、mediumint、int、bigint分别需要8、16、24、32、64。 值域范围-2^(n-1)~ 2^(n-1)-1 很多程序员在设计数据表的时候很习惯的用int压根不考虑这个问题 笔者建议能用tinyint的绝不用smallint 误区int(1) 和int(11)是一样的唯一区别是mysql客户端显示的时候显示多少位。 整形优先原则能用整形的不用其他类型替换如ip可以转换成整形保存如商品价格‘50.00元’则保存成50 (5)精确度与空间的转换。在存储相同数值范围的数据时浮点数类型通常都会比DECIMAL类型使用更少的空间。FLOAT字段使用4字节存储 数据。DOUBLE类型需要8 个字节并拥有更高的精确度和更大的数值范围DECIMAL类型的数据将会转换成DOUBLE类型。 2、  sql语句优化 mysql create table one ( id smallint(10) not null auto_increment primary key,   username char(8) not null,   password char(4) not null,   level tinyint (1) default 0,   last_login char(15) not null,   index(username,password,last_login))engineinnodb;   这是test表其中id是主键多列索引(username,password,last_login),里面有10000多条数据. | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |   -------------------------------------------------------------------------------------------------------- | one   |        0 | PRIMARY  |           1 | id          | A         |20242 |  NULL | NULL  |    | BTREE     |         |   -------------------------------------------------------------------------------------------------------- | one   |        1 | username |            1 | username    | A         |10121 |  NULL | NULL  |     | BTREE     |         |   -------------------------------------------------------------------------------------------------------- | one   |        1 | username |            2 | password    | A         |10121 |  NULL | NULL  | YES  | BTREE     |         |   -------------------------------------------------------------------------------------------------------- | one   |        1 | username |              3 | last_login  | A         |20242 |  NULL | NULL  |     | BTREE      |         |   -------------------------------------------------------------------------------------------------------- (1)    最左前缀原则 定义最左前缀原则指的的是在sql where 字句中一些条件或表达式中出现的列的顺序要保持和多索引的一致或以多列索引顺序出现只要出现非顺序出现、断层都无法利用到多列索引。 举例说明上面给出一个多列索引(username,password,last_login)当三列在where中出现的顺序如(username,password,last_login)、(username,password)、(username)才能用到索引如下面几个顺序(password,last_login)、(passwrod)、(last_login)---这三者不从username开始(username,last_login)---断层少了password都无法利用到索引。 因为Btree多列索引保存的顺序是按照索引创建的顺序检索索引时按照此顺序检索 测试以下测试不精确这里只是说明如何才能正确按照最左前缀原则使用索引。还有的是以下的测试用的时间0.00sec看不出什么时间区别因为数据量只有20003条加上没有在实体机上运行很多未可预知的影响因素都没考虑进去。当在大数据量高并发的时候最左前缀原则对与提高性能方面是不可否认的。 Ps最左前缀原则中where字句有or出现还是会遍历全表 (1.1)能正确的利用索引 l  Where子句表达式顺序是(username) mysql explain select * from one where usernameabgvwfnt;   ------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key      | key_len | ref   |rows | Extra       |   ------------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ref  | username      | username | 24      | const |5 | Using where |   ------------------------------------------------------------------------------------------   1 row in set (0.00 sec)   l  Where子句表达式顺序是(username,password) mysql explain select * from one where usernameabgvwfnt and password123456;   ------------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key      | key_len | ref | rows | Extra       |   ------------------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ref  | username      | username | 43      | const,const |    1 | Using where |   ------------------------------------------------------------------------------------------------   1 row in set (0.00 sec)   l  Where子句表达式顺序是(username,password, last_login) mysql explain select * from one where usernameabgvwfnt and password123456and last_login1338251170;   ------------------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key      | key_len | ref| rows | Extra       |   ------------------------------------------------------------------------------------------------------   |  1 | SIMPLE   | one   | ref  | username     | username | 83      | const,const,const |    1 | Using where |   ------------------------------------------------------------------------------------------------------   1 row in set (0.00 sec)   上面可以看出typeref 是多列索引key_len分别是24、43、83这说明用到的索引分别是(username), (username,password), (username,password, last_login );row分别是5、1、1检索的数据行都很少因为这三个查询都按照索引前缀原则可以利用到索引。 (1.2)不能正确的利用索引 l  Where子句表达式顺序是(password, last_login) mysql explain select * from one where password123456and last_login1338251170;   --------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows| Extra       |   --------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ALL  | NULL          | NULL | NULL    | NULL | 20146 | Using where |   --------------------------------------------------------------------------------------   1 row in set (0.00 sec)   l  Where 子句表达式顺序是(last_login) mysql explain select * from one where last_login1338252525;   --------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows| Extra       |   --------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ALL  | NULL          | NULL | NULL    | NULL | 20146 | Using where |   --------------------------------------------------------------------------------------   1 row in set (0.00 sec)   以上的两条语句都不是以username开始这样是用不了索引通过typeall(全表扫描)key_lennullrows都很大20146 Psone表里只有20003条数据为什么出现20146这是优化器对表的一个估算值不精确的。 l  Where 子句表达式虽然顺序是(username,password, last_login)或(username,password)但第一个是有范围’’、’’’’’’等出现 mysql explain select * from one where usernameabgvwfnt and password 123456and last_login1338251170;   --------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows| Extra       |   --------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ALL  | username      | NULL | NULL    | NULL | 20146 | Using where |   --------------------------------------------------------------------------------------   1 row in set (0.00 sec)   这个查询很明显是遍历所有表一个索引都没用到非第一列出现范围(password列或last_login列)则能利用索引到首先出现范围的一列也就是“where usernameabgvwfnt and password 123456and last_login1338251170;”或则“where usernameabgvwfnt and password 123456and last_login1338251170;”索引长度ref_len43,索引检索到password列所以考虑多列索引的时候把那些查询语句用的比较的列放在最后(或非第一位)。 l  断层即是where顺序(username, last_login) mysql explain select * from one where usernameabgvwfnt and last_login1338252525;   ------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key      | key_len | ref   | rows | Extra       |   ------------------------------------------------------------------------------------------   |  1 | SIMPLE   | one   | ref  | username   | username | 24     | const |5 | Using where |   ------------------------------------------------------------------------------------------   1 row in set (0.00 sec)   注意这里的key_len248*3(8是username的长度3是utf8编码)rows5和下面一条sql语句搜索出来一样 mysql  select * from one where usernameabgvwfnt;   ----------------------------------------------   | id    | username | password | level | last_login |   ----------------------------------------------   |  3597 | abgvwfnt | 234567   |     0 | 1338251420 |   |  7693 | abgvwfnt | 456789   |     0 | 1338251717 |   | 11789 | abgvwfnt | 456789   |     0 | 1338251992 |   | 15885 | abgvwfnt | 456789   |     0 | 1338252258 |   | 19981 | abgvwfnt | 456789   |     0 | 1338252525 |   ----------------------------------------------   5 rows in set (0.00 sec)     mysql  select * from one where usernameabgvwfnt and last_login1338252525;   ----------------------------------------------   | id    | username | password | level | last_login |   ----------------------------------------------   | 19981 | abgvwfnt | 456789   |     0 | 1338252525 |   ----------------------------------------------   1 row in set (0.00 sec)   这个就是要的返回结果所以可以知道断层(username,last_login)这样只用到username索引把用到索引的数据再重新检查last_login条件这个相对全表查询来说还是有性能上优化这也是很多sql优化文章中提到的where 范围查询要放在最后(这不绝对但可以利用一部分索引) (1.3)如果一个查询where子句中确实不需要password列那就用“补洞”。 mysql select distinct(password) from one;   ----------   | password |   ----------   | 234567   |   | 345678   |   | 456789   |   | 123456   |   ----------   4 rows in set (0.08 sec) 可以看出password列中只有这几个值当然在现实中不可能密码有这么多一样的再说数据也可能不断更新这里只是举例说明补洞的方法 mysql explain select * from one where usernameabgvwfnt and password in(123456,234567,345678,456789) and last_login1338251170;   ------------------------------------------------------------------------------------------   | id | select_type | table | type  | possible_keys | key      | key_len | ref  | rows | Extra       |   ------------------------------------------------------------------------------------------   |  1 | SIMPLE    | one | range | username    | username| 83      | NULL |4 | Using where |   ------------------------------------------------------------------------------------------   1 row in set (0.00 sec)   可以看出ref83 所有的索引都用到了typerange是因为用了in子句。 这个被“补洞”列中的值应该是有限的可预知的如性别其值只有男和女(加多一个不男不女也无妨)。 “补洞”方法也有瓶颈当很多列且需要补洞的相应列(可以多列)的值虽有限但很多(如中国城市)的时候优化器在优化时组合起来的数量是很大这样的话就要做好基准测试和性能分析权衡得失取得一个合理的优化方法。 (1.4)like mysql explain select * from one where username like abgvwfnt%;   ------------------------------------------------------------------------------------------   | id | select_type | table | type  | possible_keys | key      | key_len | ref  |   rows | Extra       |   ------------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | range | username      | username | 24      | NULL |   5 | Using where |   ------------------------------------------------------------------------------------------   1 row in set (0.00 sec)   mysql explain select * from one where username like %abgvwfnt%;   --------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows| Extra       |   --------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ALL  | NULL          | NULL | NULL    | NULL | 20259 | Using where |   --------------------------------------------------------------------------------------   1 row in set (0.01 sec)   对比就知道like操作abgvwfnt%能用到索引%abgvwfnt%用不到 --------------------------------------------------------------------------------------------- (2)    Order by 优化 (2.1)filesort优化算法. 在mysql version()4.1之前优化器采用的是filesort第一种优化算法先提取键值和指针排序后再去提取数据前后要搜索数据两次第一次若能使用索引则使用第二次是随机读(当然不同引擎也不同)。mysql version()4.1,更新了一个新算法就是在第一次读的时候也把selcet的列也读出来然后在sort_buffer_size中排序(不够大则建临时表保存排序顺序)这算法只需要一次读取数据。所以有这个广为人传的一个优化方法那就是增大sort_buffer_size。Filesort第二种算法要用到更的空间sort_buffer_size不够大反而会影响速度所以mysql开发团队定了个变量max_length_for_sort_data当算法中读出来的需要列的数据的大小超过该变量的值才使用所以一般性能分析的时候会尝试把max_length_for_sort_data改小。 (2.2)单独order by 用不了索引索引考虑加where 或加limit 先建一个索引(last_login),建的过程就不给出了 mysql explain select * from one order by last_login desc;   -----------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows    | Extra          |   -----------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ALL  | NULL          | NULL | NULL    | NULL | 2046   3 | Using filesort |   -----------------------------------------------------------------------------------------   1 row in set (0.00 sec)     mysql explain select * from one order by last_login desc limit 10;   --------------------------------------------------------------------------------------   | id | select_type | table | type  | possible_keys | key      | key_len | ref   | rows | Extra |   --------------------------------------------------------------------------------------   |  1 | SIMPLE   | one   | index | NULL      | last_login  | 4     | NULL   |   10 |       |   --------------------------------------------------------------------------------------   1 row in set (0.00 sec)   开始没limit查询是遍历表的加了limit后索引可以使用看key_len 和key (2.3)where orerby 类型where满足最左前缀原则且orderby的列和where子句用到的索引的列的子集。即是(a,b,c)索引where满足最左前缀原则且order by中列a、b、c的任意组合 mysql explain select * from one where usernameabgvwfnt and password 123456   and last_login1338251001 order by password desc,last_login desc;     ------------------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key      | key_len | ref       | rows | Extra       |   ------------------------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ref  | username      | username | 83      | const,c   onst,const |    1 | Using where |   ------------------------------------------------------------------------------------------------------   1 row in set (0.00 sec)     mysql explain select * from one where usernameabgvwfnt and password 123456   and last_login1338251001 order by password desc,level desc;   ---------------------------------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key      | key_len | ref| rows | Extra                       |   ----------------------------------------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ref  | username      | username | 83      | const,c   onst,const |    1 | Using where; Using filesort |   ----------------------------------------------------------------------------------------------------------------------     1 row in set (0.00 sec)   上面两条语句明显的区别是多了一个非索引列level的排序在extra这列对了Using filesort 笔者测试结果where满足最左前缀且order by中的列是该多列索引的子集时(也就是说orerby中没最左前缀原则限制)不管是否有asc ,desc混合出现都能用索引来满足order by。 笔者测试过因为篇幅比较大这里就不一一列出。 Ps:很优化博文都说order by中的列要where中出现的列(是索引)的顺序一致笔者认为不够严谨。 (2.3) where orerbylimit 这个其实也差不多只要where最左前缀orderby也正确limit在此影响不大 (2.4)如何考虑order by来建索引 这个回归到创建索引的问题来在比较常用的oder by的列和where中常用的列建立多列索引这样优化起来的广度和扩张性都比较好当然如果要考虑UNION、JOIN、COUNT、IN等进来就复杂很多了 (3)    隔离列 隔离列是只查询语句中把索引列隔离出来也就是说不能在语句中把列包含进表达式中如id12、inet_aton(210.38.196.138)---ip转换成整数、convert(123,char(3))---数字转换成字符串、date函数等mysql内置的大多函数。 非隔离列影响性能很大甚至是致命的这也就是赶集网石展的《三十六军规》中的一条虽然他没说明是隔离列。 以下就测试一下 首先建立一个索引(last_login )这里就不给出建立的代码了且把last_login改成整型(这里只是为了方便测试并不是影响条件) mysql explain select * from one where last_login 8388605;   ---------------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key        | key_len | ref | rows  | Extra       |   ---------------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ref  | last_login    | last_login | 3       | const   | 1 | Using where |   ---------------------------------------------------------------------------------------------   1 row in set, 1 warning (0.00 sec)   容易看出建的索引已起效 mysql explain select * from one where last_login 1 8388606 ;   --------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows    | Extra       |   --------------------------------------------------------------------------------------   |  1 | SIMPLE      | one   | ALL  | NULL          | NULL | NULL    | NULL | 2049   7 | Using where |   --------------------------------------------------------------------------------------   1 row in set (0.00 sec)   last_login 18388608非隔离列的出现导致查找的列20197说明是遍历整张表且索引不能使用。 这是因为这条语句要找出所有last_login的数据然后1再和20197比较优化器在这方面比较差性能很差。 所以要尽可能的把列隔离出来如last_login 18388606改成login_login8388607,或者把计算、转换等操作先用php函数处理过再传递给mysql服务器 (4)    OR、IN、UNION ALL可以尝试用UNION ALL (4.1)or会遍历表就算有索引 mysql explain select * from one where username abgvwfnt or password123456;   --------------------------------------------------------------------------------------   | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows|  Extra       |   --------------------------------------------------------------------------------------   |  1 | SIMPLE   | one  | ALL  | username   | NULL | NULL    | NULL | 20259 | Using where |   --------------------------------------------------------------------------------------   1 row in set (0.00 sec)   (4.2)对于in这个是有争议的网上很多优化方案中都提到尽量少用in这不全面其实在in里面如果是常量的话可一大胆的用in这个也是赶集网石展、阿里hellodab的观点(笔者从微博中获知)。应用hellodab一句话“MySQL用IN效率不好通常是指in中嵌套一个子查询因为MySQL的查询重写可能会产生一个不好的执行计划而如果in里面是常量的话我认为性能没有任何问题可以放心使用”---------当然对于这个比较的话没有实战数据的话很难辩解就算有影响性能的因素也很多也许会每个dba都有不同的测试结果.这也签名最左前缀中“补洞”一个方法 (4.3)UNION All 直接返回并集可以避免去重的开销。之所说“尝试”用UNION All 替代 OR来优化sql语句因为这不是一直能优化的了这里只是作为一个方法去尝试。 (5)    索引选择性 索引选择性是不重复的索引值也叫基数(cardinality)表中数据行数的比值索引选择性基数/数据行基数可以通过“show index from 表名”查看。 高索引选择性的好处就是mysql查找匹配的时候可以过滤更多的行唯一索引的选择性最佳值为1。 那么对于非唯一索引或者说要被创建索引的列的数据内容很长那就要选择索引前缀。这里就简单说明一下 mysql select count(distinct(username))/count(*)  from one;   ------------------------------------   | count(distinct(username))/count(*) |   ------------------------------------   |                             0.2047 |   ------------------------------------   1 row in set (0.09 sec)   count(distinct(username))/count(*)就是索引选择性的值这里0.2太小了。 假如username列数据很长则可以通过 select count(distinct(concat(first_name, left(last_name, N))/count(*)  from one;测试出接近1的索引选择性其中N是索引的长度穷举法去找出N的值然后再建索引。 (6)    重复或多余索引 很多phper开始都以为建索引相对多点性能就好点压根没考虑到有些索引是重复的比如建一个(username),(username,password), (username,password,last_login),很明显第一个索引是重复的因为后两者都能满足其功能。 要有个意识就是在满足功能需求的情况下建最少索引。对于INNODB引擎的索引来说每次修改数据都要把主键索引辅助索引中相应索引值修改这可能会出现大量数据迁移分页以及碎片的出现。 3、系统配置与维护优化 (1)    重要的一些变量 l  key_buffer_size索引块缓存区大小, 针对MyISAM存储引擎,该值越大,性能越好.但是超过操作系统能承受的最大值,反而会使mysql变得不稳定. ----这是很重要的参数 l  sort_buffer_size 这是索引在排序缓冲区大小若排序数据大小超过该值则创建临时文件注意和myisam_sort_buffer_size的区别----这是很重要的参数 l  read_rnd_buffer_size当排序后按排序后的顺序读取行时则通过该缓冲区读取行避免搜索硬盘。将该变量设置为较大的值可以大大改进ORDER BY的性能。但是这是为每个客户端分配的缓冲区因此你不应将全局变量设置为较大的值。相反只为需要运行大查询的客户端更改会话变量 l  join_buffer_size用于表间关联(join)的缓存大小 l  tmp_table_size缓存表的大小 l  table_cache允许 MySQL 打开的表的最大个数并且这些都cache在内存中 l  delay_key_write针对MyISAM存储引擎,延迟更新索引.意思是说,update记录时,先将数据up到磁盘,但不up索引,将索引存在内存里,当表关闭时,将内存索引,写到磁盘 更多参数查看http://www.phpben.com/?post70 (2)    optimize、Analyze、check、repair维护操作 l  optimize 数据在插入更新删除的时候难免一些数据迁移分页之后就出现一些碎片久而久之碎片积累起来影响性能这就需要DBA定期的优化数据库减少碎片这就通过optimize命令。 如对MyisAM表操作optimize table 表名 对于InnoDB表是不支持optimize操作否则提示“Table does not support optimize, doing recreate analyze instead”当然也可以通过命令alter table one typeinnodb; 来替代。 l  Analyze 用来分析和存储表的关键字的分布使得系统获得准确的统计信息影响 SQL 的执行计划的生成。对于数据基本没有发生变化的表是不需要经常进行表分析的。但是如果表的数据量变化很明显用户感觉实际的执行计划和预期的执行计划不 同的时候执行一次表分析可能有助于产生预期的执行计划。 Analyze table 表名 l  Check检查表或者视图是否存在错误对 MyISAM 和 InnoDB 存储引擎的表有作用。对于 MyISAM 存储引擎的表进行表检查也会同时更新关键字统计数据 l  Repair optimize需要有足够的硬盘空间否则可能会破坏表导致不能操作那就要用上repair注意INNODB不支持repair操作 以上的操作出现的都是如下这是check --------------------------------------------   | Table  | Op  | Msg_type| Msg_text |   --------------------------------------------   | test.one | check | status  | OK     |   --------------------------------------------   其中op是option 可以是repair check optimizemsg_type 表示信息类型msg_text 表示信息类型这里就说明表的状态正常。如在innodb表使用repair就出现note | The storage engine for the table doesnt support repair 注意以上操作最好在数据库访问量最低的时候操作因为涉及到很多表锁定扫描数据迁移等操作否则可能导致一些功能无法正常使用甚至数据库崩溃。 (3)表结构的更新与维护 l  改表结构。当要在数据量千万级的数据表中使用alter更改表结构的时候这是一个棘手问题。一种方法是在低并发低访问量的时候用平常的alter更改表。另外一种就是建另一个与要修改的表这个表除了要修改的结构属性外其他的和原表一模一样这样就能得到一个相应的.frm文件然后用flush with read lock 锁定读然后覆盖用新建的.frm文件覆盖原表的.frm最后unlock table 释放表。 l  建立新的索引。一般方法这里不说。 1、  创建没索引的a表导入数据形成.MYD文件。 2、  创建包括索引b表形成.FRM和.MYI文件 3、  锁定读写 4、  把b表的.FRM和.MYI文件改成a表名字 5、  解锁 6、  用repair创建索引。 这个方法对于大表也是很有效的。这也是为什么很多dba坚持说“先导数据库在建索引这样效率更快” l  定期检查mysql服务器 定期使用show status、show processlist等命令检查数据库。这里就不细说这说起来也篇幅是比较大的笔者对这个也不是很了解 第四部分图说mysql查询执行流程 1、  查询缓存判断sql语句是否完全匹配再判断是否有权限两个判断为假则到解析器解析语句为真则提取数据结果返回给用户。 2、  解析器解析。解析器先词法分析语法分析检查错误比如引号有没闭合等然后生成解析树。 3、  预处理。预处理解决解析器无法决解的语义如检查表和列是否存在别名是否有错生成新的解析树。 4、  优化器做大量的优化操作。 5、  生成执行计划。 6、  查询执行引擎负责调度引擎获取相应数据 7、  返回结果。     这篇博文准备写将用了一个月时间终于写完但真的学了很多东西 有纰漏请联系benwin(bw7bus.net/445235728qq.com)     参考 http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html http://www.cnblogs.com/oldhorse/archive/2009/11/16/1604009.html http://blog.csdn.net/zuiaituantuan/article/details/5909334 http://www.codinglabs.org/html/theory-of-mysql-index.html http://isky000.com/database/mysql_order_by_implement http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html   http://www.docin.com/p-211669085.html 觉得文章有用立即 和朋友一起 共学习 共进步 建议继续学习 浅谈MySQL索引背后的数据结构及算法    (阅读5688)由浅入深理解索引的实现(2)    (阅读4703)如何建立合适的索引    (阅读4419)HBase二级索引与Join    (阅读4140)InnODB和MyISAM索引统计集合    (阅读4124)Innodb 表和索引结构    (阅读3802)MySQL索引背后的数据结构及算法原理    (阅读3564)多维度分类排行榜应用用位图索引    (阅读3280)如何建立索引    (阅读3179)mysql索引浅析    (阅读3113) 转载于:https://www.cnblogs.com/mr-amazing/p/4535544.html