主要分为以下四⼤⽅⾯：
设计：存储引擎，字段类型，范式与逆范式功能：索引，缓存，分区分表。
架构：主从复制，读写分离，负载均衡。合理SQL：测试，经验。⼀、存储引擎
在创建表的时候我们使⽤sql语句，Create table tableName () engine=myisam|innodb;
这⾥就指明了存储引擎是myisam还是innodb。存储引擎是⼀种⽤来存储MySQL中对象（记录和索引）的⼀种特定的结构（⽂件结构），处于MySQL服务器的最底层，直接存储数据。导致上层的操作，依赖于存储引擎的选择。地位如下图：
⽹络接⼝层：与客户端通信，⽐如传输数据等等。存储引擎层：存储数据的规则，⽅式。本质：存储引擎就是特定的数据存储格式（⽅案）。
可以使⽤show engines命令来查看当前MySQL⽀持的存储引擎列表。
1、InnoDB存储引擎介绍
Mysql版本>=5.5 默认的存储引擎，MySQL推荐使⽤的存储引擎。⽀持事务，⾏级锁定，外键约束。事务安全型存储引擎。更加注重数据的完整性和安全性。（1）存储格式
数据，索引集中存储，存储于同⼀个表空间⽂件中。
数据：记录⾏。索引：⼀种检索机制，也需要⼀定的空间，就相当于⼀本字典的⽬录。
⽰例： 创建⼀个test，新建⼀张student表，选择存储引擎为innodb, 然后打开的data下的test⽬录，发现有以下3个⽂件。
其中db.opt存放了数据库的配置信息，⽐如数据库的字符集还有编码格式。student.frm是表结构⽂件，仅存储了表的结构、元数据(meta)，包括表结构定义信息等。不论是哪个表引擎都会有⼀个frm⽂件。student.ibd是表索引⽂件，包括了单独⼀个表的数据及索引内容。如果往表⾥插⼊了新的数据，则在mysql的data⽬录下会⽣成ibdata1⽂件，这个⽂件是存储了所有innodb表的数据。
关于innodb引擎的详细介绍：
使⽤innodb引擎时，需要理解独⽴表空间、共享表空间。
独⽴表空间：每个表都会⽣成以独⽴的⽂件⽅式来存储，每个表都⼀个.frm的描述⽂件，还有⼀个.ibd⽂件。其中这个⽂件包括了单独⼀个表的数据及索引内容，默认情况下它的存储在mysql指定的⽬录下。独⽴表空间优缺点优点：
每个表都有⾃⼰独⽴的表空间；每个表的数据和索引都会存储在各个独⽴的表空间中；可以实现单表在不同的数据进⾏迁移；表空间可以回收（除了drop table操作，表空不能⾃⼰回收）；drop table 操作⾃动回收表空间，如果对统计分析或是⽇值表，删除⼤量数据后可以通过：alter table tablename engin=innodb进⾏回缩不⽤的空间；对于使⽤inodb-plugin的innodb使⽤truncate table会使⽤空间收缩。；对于使⽤独⽴表空间，不管怎么删除，表空间的碎⽚都不会太严重。缺点：
单表增加过⼤，如超过100G。对于单表增长过⼤的问题，如果使⽤共享表空间可以把⽂件分开，但有同样有⼀个问题，如果访问的范围过⼤同样会访问多个⽂件，⼀样会⽐较慢。对于独⽴表空间也有⼀个解决办法是：使⽤分区表，也可以把那个⼤的表空间移动到别的空间上然后做⼀个连接。其实从性能上出发，当⼀个表超过100个G有可能响应也是较慢了，对于独⽴表空间还容易发现问题早做处理。
共享表空间：某⼀个数据库所有的表数据，索引⽂件全部都放在⼀个⽂件中，默认这个共享表空间的⽂件路径在data⽬录下，默认的⽂件名为 ibdata1,初始化为10M。共享表空间优缺点
优点：可以将表空间分成多个⽂件存放在各个磁盘上（表空间⽂件⼤⼩不受表⼤⼩的限制，如⼀个表可以分布在不同的⽂件上），数据和⽂件放在⼀起⽅便管理。
缺点：所有的数据和索引存放到⼀个⽂件中，将来会是⼀个很⼤的⽂件，虽然可以把⼀个⼤⽂件分成多个⼩⽂件，但是多个表及索引在表空间中混合存储，这样对⼀个表做了⼤量删除操作后表空间将有⼤量的空隙，特别是对统计分析、⽇值这类应⽤最不适合⽤共享表空间。如何开启独⽴表空间？查看是否开启独产表空间：
mysql> show variables like '%per_table';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| innodb_file_per_table | OFF |+-----------------------+-------+
设置开启：
在my.cnf⽂件中[mysqld] 节点下添加innodb_file_per_table=1或者通过命令：set global innodb_file_per_table=1;注：
innodb_file_per_table值来进⾏修改即可，但是对于之前使⽤过的共享表空间则不会影响，除⾮⼿动的去进⾏修改或者是
innodb_file_per_table=1 为使⽤独占表空间innodb_file_per_table=0 为使⽤共享表空间修改独占空表空间的数据存储位置innodb_data_home_dir = \"C:\\mysql\\data\\\"innodb_log_group_home_dir = \"C:\\mysql\\data\\\"innodb_data_file_path=ibdata1:10M:autoextendinnodb_file_per_table=1参数说明:
这个设置配置⼀个可扩展⼤⼩的尺⼨为10MB的单独⽂件，名为ibdata1。没有给出⽂件的位置，所以默认的是在MySQL的数据⽬录内。【对数据来进⾏初始化的设置】
innodb_data_home_dir 代表为数据库⽂件所存放的⽬录innodb_log_group_home_dir 为⽇志存放⽬录innodb_file_per_table 是否使⽤共享以及独占表空间来以上的⼏个参数必须在⼀起加⼊。对于参数⼀些注意的地⽅
InnoDB不创建⽬录，所以在启动服务器之前请确认”所配置的路径⽬录”的确存在。这对你配置的任何⽇志⽂件⽬录来说也是真实的。使⽤Unix或DOS的mkdir命令来创建任何必需的⽬录。
通过把innodb_data_home_dir的值原原本本地部署到数据⽂件名，并在需要的地⽅添加斜杠或反斜杠，InnoDB为每个数据⽂件形成⽬录路径。
如果innodb_data_home_dir选项根本没有在my.cnf中提到，默认值是“dot”⽬录 ./，这意思是MySQL数据⽬录。（2）数据按照主键顺序存储
插⼊时做排序⼯作，效率低。（3）特定功能
事务、外键约束 ： 都是为了维护数据的完整性。并发性处理：
innodb擅长处理并发的。因为它使⽤了⾏级锁定，只该⾏锁了，其它⾏没有锁。
⾏级锁定：row-level locking，实现了⾏级锁定，在⼀定情况下，可以选择⾏级锁来提升并发性。也⽀持表级锁定，Innodb会⾃带锁，不需要我们⾃⼰设置。
多版本并发控制, MVCC，效果达到⽆阻塞读操作。
（4）总结：innodb擅长事务、数据的完整性及⾼并发处理，不擅长快速插⼊（插⼊前要排序，消耗时间）和检索。2.MyISAM存储引擎介绍
MySQL<= 5.5 MySQL默认的存储引擎。
ISAM：Indexed Sequential Access Method(索引顺序)的缩写，是⼀种⽂件系统。擅长与处理，⾼速读与写。（1）存储⽅式
数据和索引分别存储于不同的⽂件中。
（2）数据的存储顺序为插⼊顺序（没有经过排序）
插⼊速度快，空间占⽤量⼩。（3）功能
a.全⽂索引⽀持。（mysql>=5.6时innodb 也⽀持）b.数据的压缩存储。.MYD⽂件的压缩存储。压缩前，数据是25600KB：
进⾏压缩：使⽤⼯具 myisamPack完成压缩功能：该⼯具mysql⾃带
进⼊到需要压缩表的数据⽬录，执⾏压缩指令 myisampack 表名。配置环境变量。
压缩后：
注意，压缩后，需要重新修复索引：
查看结果，发现现在的数据变成12741KB了，⽐之前的更⼩了：
压缩优势：节省磁盘空间，减少磁盘IO开销。特点：压缩后的表变成了只读表，不可写。如果需要更新数据，则需要先解压后更新。利⽤⼯具：myisamchk –unpack 表名 进⾏解压
解压后，变成了原来的25600KB
刷新表的状态：flush table myisam_2
c.并发性：
仅仅⽀持表级锁定，不⽀持⾼并发。
⽀持并发插⼊。写操作中的插⼊操作，不会阻塞读操作（其他操作）（4）关于Innodb 和myisam的取舍：
Innodb ：数据完整性，并发性处理，擅长更新，删除。myisam：⾼速查询及插⼊。擅长插⼊和查询。具体举例：
那么对于微博项⽬来看，选择哪⼀个存储引擎呢？
a.微博主要是插⼊微博和查询微博列表，较为适合MyISAM；b.微博在更新微博和删除微博，要少的多，较为适合MyISAM；
c.对数据完整性的需求并没有那么强烈，⽐如⽤户删除微博，关联的转播和评论并不要求都做相应的⾏为，较为适合MyISAM；那么对于记账财务系统，选择哪⼀款存储引擎呢？
a.财务系统除了读取和插⼊，经常要进⾏数据的修改和删除，较为适合InnoDB；b.在进⾏财务变更的时候，如果失败需要回滚必须⽤到事务，较为适合InnoDB；
c.每个⽤户的财务数据完整性和同步性⾮常重要，需要外键⽀持，否则财务将会混乱，较为适合InnoDB。3.其他存储引擎
（1）Archive：存档型，仅提供插⼊和查询操作。⾮常⾼效阻塞的插⼊和查询。（2）Memory：内存型，数据存储于内存中，存储引擎。缓存型存储引擎。（3）插件式存储引擎：⽤C和C++开发的存储引擎。
4.锁的概念：当客户端操作表（记录）时，为了保证操作的隔离性（多个客户端操作不能互相影响），通过加锁来处理。操作⽅⾯：
读锁：读操作时增加的锁，也叫共享锁，S-lock。特征是阻塞其他客户端的写操作，不阻塞读操作。（并发读）写锁：写操作时增加的锁，也叫独占锁或排他锁，X-lock。特征是阻塞其他客户端的读，写操作。锁定粒度（范围）：
⾏级：提升并发性，锁本⾝开销⼤表级：不利于并发性，锁本⾝开销⼩。⼆、字段类型选择
字段类型应该要满⾜需求，尽量要满⾜以下需求。
尽可能⼩（占⽤存储空间少）、尽可能定长（占⽤存储空间固定）、尽可能使⽤整数。
1.列类型之数值（1）整型
MySQL数据库⽀持五种整型类型，包括：TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT五种。整型类型占⽤空间和取值范围类型 字节 最⼩值 最⼤值
TINYINT 1 有符号：-128 ⽆符号：0 有符号：127 ⽆符号：255SMALLINT 2有符号：-32768⽆符号：0有符号：32767⽆符号：65535
MEDIUMINT 3有符号：-8388608⽆符号：0有符号：8388607⽆符号：16777215
INT/INTEGER 4有符号：-2147483648⽆符号：0有符号：2147483647⽆符号：4294967295
BIGINT 8 有符号：-9223372036854775808⽆符号：0 有符号：9223372036854775807⽆符号：18446744073709551615五种整型的适⽤场景：
TINYINT，年龄，包含在0~255之间；SMALLINT，端⼝号，包含在0~65535之间；MEDIUMINT，中⼩型⽹站注册会员，1600万够⽤；INT，⾝份证编号，42亿可以⽤很久；BIGINT，Twitter微博量，⼏百亿（2）浮点型(⾮精确)
MySQL数据库⽀持两种浮点类型：FLOAT(单精度)和DOUBLE(双精度)两种浮点型(⾮精确)占⽤空间和取值范围类型 字节 范围
FLOAT 4 正数范围：1.175494351E-38~3.402823466E+38，负数范围：-3.402823466E+38~-1.175494351E-38DOUBLE 8 正数范围：1.7976931348623157E-308~2.2250738585072014E+308负数范围：-2.2250738585072014E+308~-1.7976931348623157E-308（3）定点型(精确)
浮点型由于内部的存储⽅式是数值，导致它在⼀定程度上取得的是近似值⽽⾮精确值。如果使⽤定点型，那么就可以精确取得⼩数部分，因为它内部存储⽅式是字符串形式。定点型(精确)占⽤空间和取值范围类型 字节 范围
DECIMAL/NUMERIC M+2 M最⼤65位，D最⼤30位。
创建⼀个定点型格式：DECIMAL(M,D)，表⽰⼩数点D位，整数部分M位及M位内。2.列类型之⽇期
MySQL数据库中有五个可⽤的⽇期时间数据类型，分别为：DATE、DATETIME、TIME、YEAR、TIMESTAMP。⽇期时间类型占⽤空间和取值范围类型 字节 最⼩值 最⼤值YEAR 1 1901 2155
TIME 3 -838:59:59838:59:59DATE 4 1000-01-01 9999-12-31
TIMESTAMP 4 1970-01-01 00:00:00 2038-01-19 03:14:07DATETIME 8 1000-01-01 00:00:00 9999-12-31 23:59:59
TIMESTAMP有⼏个特点：
a.当更新⼀条数据的时候，设置此类型根据当前系统更新可⾃动更新时间；b.如果插⼊⼀条NULL，也会⾃动插⼊当前系统时间；c.创建字段时，系统会⾃动给⼀个默认值；
d.会根据当前时区来存储和查询时间，存储时对当前时区进⾏转换，查询时再转换为当前的时区。//查看当前时区
SHOW VARIABLES LIKE 'time_zone';//设置为东九区，查询时间就会加1⼩时SET time_zone='+9:00';
DATE占⽤3个字节，包含年⽉⽇，范围和DATETIME⼀样。DATE长度是0，⽆法设置。YEAR占⽤1个字节，包年年份，长度默认为4位，⽆法设置。
TIME占⽤3个字节，包含时分秒，长度0到6之间，⽤于设置微秒。对于TIME的范围的时是-838到838的原因，是因为TIME类型不但可以保存⼀天的时，还可以包含时间之间的间隔。
综上考虑：使⽤datetime，当然也可以使⽤int（11）来保存时间戳。关于INT(11)存放时间戳的优点如下：a.INT占4个字节，DATETIME占8个字节；
b.INT存储索引的空间⽐DATETIME⼩，查询快，排序效率⾼；c.在计算机时间差等范围问题，⽐较⽅便。3.列类型之字符
字符集校对规则utf8_general_ci表⽰校对时不区分⼤⼩写，相对的cs表⽰区分⼤⼩写。还有⼀个bin结尾的是字节⽐较。⽽general是地区名，这⾥是通⽤，utf8表⽰编码。如果是gbk，可以使⽤gbk_chinese_ci，如果是utf8则⽤utf8_general。MySQL提供了多种对字符数据的存储类型，包括：CHAR、VARCHAR、VARBINARY、BLOB、TEXT、ENUM和SET等多种字符类型。
（1）CHAR是保存定长字符串，⽽VARCHAR则是保存变长字符串。CHAR(5)表⽰必须保存5个字符，⽽VARCHAR(5)则表⽰最⼤保存字符为5。如果是UTF8编码下，长度为5的CHAR类型，最多可以存储15字节，也就是5个汉字的内容。因为⼀个汉字占3个字节。
由于CHAR类型是定长，MySQL会根据定义的长度进⾏分配空间，在处理速度上⽐VARCHAR快的多，所以适合存储例如⼿机、⾝份证这种定长的字符，否则就会造成浪费。那么CHAR类型最⼤可以插⼊255个字符，最多可以存储765个字节。
（2）BINARY和VARBINARY是采⽤⼆进制存储的，没有字符集概念，意义在于防⽌字符集的问题导致数据丢失，存储中⽂会占⽤两个字符，会乱码，半截会问号。因为是采⽤⼆进制存储，在⽐较字符和排序的时候，都是⼆进制进⾏的，所以只有需要操作⼆进制时才需要使⽤。
（3）⼋种适合⽂本内容的⼤数据类型：TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT、TINYBLOG、BLOB、MEDIUMTEXT、LONGTEXT。
综上：短⽂本定长⽤char，变长⽤varchar，长⽂本⽤text4.列类型之属性
⽆符号(UNSIGNED)和填充零(ZEROFILL)，还有是否为空、默认值、主键、⾃动编号。严格模式
我们使⽤的是WAMP集成环境，默认安装的情况下，是⾮严格模式，⽤于部署阶段。⽽开发调试阶段，强烈建议使⽤严格模式，⽅便开发中调试将问题及时暴露出来。因为在⾮严格模式下将NULL插⼊NOTNULL等⾮法操作都是被运⾏的。设置严格模式只要打开my.ini⽂件，在末尾添加⼀句：
sql-mode=\"STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION\"然后，重启服务器即可。检查SQL_MODE状态SELECT @@global.sql_mode;三、范式与逆范式
为了建⽴冗余较⼩、结构合理的数据库，设计数据库时必须遵循⼀定的规则。在关系型数据库中这种规则就称为范式。范式是符合某⼀种设
计要求的总结。要想设计⼀个结构合理的关系型数据库，必须满⾜⼀定的范式。第⼀范式1NF，原⼦性第⼆范式2NF，消除部分依赖第三范式3NF，消除传递依赖1、范式
（1）第⼀范式：具有原⼦性，确保每列保持原⼦性。
第⼀范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原⼦值，就说明该数据库表满⾜了第⼀范式。第⼀范式的合理遵循需要根据系统的实际需求来定。⽐如某些数据库系统中需要⽤到“地址”这个属性本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储，这样在对地址中某⼀部分操作的时候将⾮常⽅便。这样设计才算满⾜了数据库的第⼀范式。
（2）第⼆范式：主键列与⾮主键列遵循完全函数依赖关系，确保表中的每列都和主键相关。
第⼆范式在第⼀范式的基础之上更进⼀层。第⼆范式需要确保数据库表中的每⼀列都和主键相关，⽽不能只与主键的某⼀部分相关（主要针对联合主键⽽⾔）。也就是说在⼀个数据库表中，⼀个表中只能保存⼀种数据，不可以把多种数据保存在同⼀张数据库表中。（3）第三范式：⾮主键列之间没有传递函数依赖关系索引，确保每列都和主键列直接相关,⽽不是间接相关。
所谓传递函数依赖，指的是如果存在\"A→B→C\"的决定关系，则C传递函数依赖于A。因此，满⾜第三范式的数据库表应该不存在如下依赖关系：
关键字段→⾮关键字段x→⾮关键字段y
⽐如在设计⼀个订单数据表的时候，可以将客户编号作为⼀个外键和订单表建⽴相应的关系。⽽不可以在订单表中添加关于客户其它信息（⽐如姓名、所属公司等）的字段。
先满⾜第⼀范式，再满⾜第⼆范式，才能满⾜第三范式。2、逆范式
逆范式是指打破范式，通过增加冗余或重复的数据来提⾼数据库的性能。⽰例： 假如有⼀个商品表Goods：
字段有Goods_id(商品表), goods_name(商品名称), cat_id(所属类别的id)。还有⼀个分类表Category：
字段有Cat_id(类别id), cat_name(类别名称)。
现在要查询类别id为3的商品的数量，例如分类列表查询：分类ID 分类名称 商品数量3 计算机 567
可以使⽤下列sql语句：
Select c.*, count(g.goods_id) as goods_count from category as c left join goods as g c.cat_id=g.cat_id group by c.cat_id;
但是，假如商品数量较⼤，那么就⽐较耗性能了。这时，我们可以考虑重新设计Category表：增加存当前分类下商品数量的字段。Cat_id, cat_name, goods_count
每当商品改动时，修改对应分类的数量信息。再查询分类列表时：Select * from category;
此时额外的消耗，出现在维护该字段的正确性上，保证商品的任何更新都正确的处理该数量才可以。四、索引1．索引概述
利⽤关键字，就是记录的部分数据（某个字段，某些字段，某个字段的⼀部分），建⽴与记录位置的对应关系，就是索引。索引的关键字⼀定是排序的。索引本质上是表字段的有序⼦集，它是提⾼查询速度最有效的⽅法。⼀个没有建⽴任何索引的表，就相当于⼀本没有⽬录的书，在每次查询时就会进⾏全表扫描，这样会导致查询效率极低、速度也极慢。如果建⽴索引，那么就好⽐⼀本添加的⽬录，通过⽬录的指引，迅速翻阅到指定的章节，提升的查询性能，节约了查询资源。测试查询，添加索引前后⽐对执⾏时间：
2．索引种类
从索引的定义⽅式和⽤途中来看：主键索引，唯⼀索引，普通索引，全⽂索引。
⽆论任何类型，都是通过建⽴关键字与位置的对应关系来实现的。索引是通过关键字找对应的记录的地址。以上类型的差异：对索引关键字的要求不同。
关键字：记录的部分数据（某个字段，某些字段，某个字段的⼀部分）。普通索引,index：对关键字没有要求。
唯⼀索引,unique index：要求关键字不能重复。同时增加唯⼀约束。
主键索引,primary key：要求关键字不能重复，也不能为NULL。同时增加主键约束。全⽂索引,fulltext key：关键字的来源不是所有字段的数据，⽽是从字段中提取的特别关键词。
关键字含义：可以是某个字段，也可以是某些字段。如果⼀个索引通过在多个字段上提取的关键字，称之为复合索引。 命令:alter table expadd index (field1, field2);
PS：这⾥主键索引和唯⼀索引的区别在于：主键索引不能为空值，唯⼀索引允许空值；主键索引在⼀张表内只能创建⼀个，唯⼀索引可以创建多个。主键索引肯定是唯⼀索引，但唯⼀索引不⼀定是主键索引。3.索引操作(1)创建主键索引
创建⼀个⽆符号整型且⾃动增长的列，然后设置成主键即可。//通过EXPLAIN语句查看索引状态
EXPLAIN SELECT * FROM think_user WHERE id=1;(2)创建普通或唯⼀索引
直接进⼊navicat设计表的第⼆栏，选择⼀个字段(⽐如user字段)，添加⼀个Nomral(普通索引)或Unique(唯⼀索引)。//通过EXPLAIN语句查看索引状态
EXPLAIN SELECT * FROM think_user WHERE user='蜡笔⽼新';//查看表所有索引情况
SHOW INDEX FROM think_user;
（3）使⽤sql语句的⽅式建⽴索引----建表时就创建索引
注意：索引可以起名字，但是主键索引不能起名字，因为⼀个表仅仅可以有⼀个主索引，其他索引可以出现多个。名字可以省略，mysql会默认⽣成，通常使⽤字段名来充当。
（4）使⽤sql语句的⽅式建⽴索引----更新表时创建索引
注意：如果表中存在数据，数据符合唯⼀或主键的约束才可能创建成功。auto_increment属性，依赖于⼀个KEY。（5）使⽤sql语句的⽅式删除索引，auto_increment依赖于KEY。
（6）Explain 执⾏计划
可以通过在select语句前使⽤ explain，来获取该查询语句的执⾏计划，⽽不是真正执⾏该语句。
删除索引时，再看执⾏计划：
从查询的⾏数可知，有索引时查询会快的多，因为它只需要查找⼀⾏，⽽没有索引时，会造成全表扫描。注意：select语句才能获取到执⾏计划。（新版本5.6会扩展其他语句的执⾏计划的获取）4.索引原则
如果索引不遵循使⽤原则，则可能导致索引⽆效。（1）列独⽴
如果需要某个字段上使⽤索引，则需要在字段参与的表达中，保证字段独⽴在⼀侧。
第三个语句 empno-1就不是列独⽴：就不能⽤索引。类似函数等等。（write_time < unix_timestamp()-$gc_maxlifetime）
其他两个列独⽴可以使⽤：
（2）左原则
Like：匹配模式必须要左边确定不能以通配符开头。
假如业务逻辑上出现: field like ‘%keywork%’;类似查询，需要使⽤全⽂索引。复合索引：⼀个索引关联多个字段，仅仅针对左边字段有效果。⽰例：添加复合索引
对Ename的查询，使⽤了索引，结果如下：
Empno的查询没有使⽤索引，结果如下：
（3）OR的使⽤
必须要保证 OR 两端的条件都存在可以⽤的索引，该查询才可以使⽤索引。
为后⾯的条件增加可以使⽤的索引后，再查看执⾏计划：
（4）MySQL智能选择
即使满⾜了上⾯说原则，MySQL也能弃⽤索引：如下图
弃⽤索引的主要原因：
查询即使使⽤索引，会导致出现⼤量的随机IO，相对于从数据记录的第⼀条遍历到最后⼀条的顺序IO开销，还要⼤。
综上归纳：
a、不要过度索引。索引越多，占⽤空间越⼤，反⽽性能变慢；b.只对WHERE⼦句中频繁使⽤的建⽴索引；
c.尽可能使⽤唯⼀索引，重复值越少，索引效果越强；
d.使⽤短索引，如果char(255)太⼤，应该给它指定⼀个前缀长度，⼤部分情况下前10位或20位值基本是唯⼀的，那么就不要对整个列进⾏索引；
e.充分利⽤左前缀，这是针对复合索引，因为WHERE语句如果有AND并列，只能识别⼀个索引(获取记录最少的那个)，索引需要使⽤复合索引，那么应该将WHERE最频繁的放置在左边。f.索引存在，如果没有满⾜使⽤原则，也会导致索引⽆效：
5.索引的使⽤场景
（1）索引检索：检索数据时使⽤索引。（2）索引排序
如果order by 排序需要的字段上存在索引，则可能使⽤到索引。例如，按照ename字段排序查询：
此时，没有任何索引。在ename字段上建⽴索引后：
不会⽤到查询检索索引是因为没有⽤where条件查询，⽽真实执⾏时，就会⽤到排序索引。Tip：对⽐以上两个执⾏计划：extra位置：
其中：extra额外信息。加了索引后就不⽤使⽤⽂件排序了。Using filesort，表⽰使⽤⽂件排序（外部排序，内存外部）。（3）索引覆盖
索引拥有的关键字内容，覆盖了查询所需要的全部数据，此时，就不需要在数据区获取数据，仅仅在索引区即可。覆盖就是直接在索引区获取内容，⽽不需要在数据区获取。
例如，利⽤名字检索：
可以在ename字段建⽴索引：
分析执⾏：
再增加⼀个索引：
完成相同的查询：
查询的字段刚好是复合索引包含的字段。所以就使⽤了复合索引。说明，不是⾮要查询⽤到，才可以索引覆盖，只要满⾜要求都可以覆盖！
建⽴索引索引时，不要仅仅考虑where检索，同时考虑其他的使⽤场景。（在所有的where字段上增加索引，就是不合理的）6.前缀索引
前缀索引是建⽴索引关键字⼀种⽅案。通常会使⽤字段的整体作为索引关键字。有时，即使使⽤字段前部分数据，也可以去识别某些记录。就⽐如⼀个班级⾥，我要找王xx，假如姓王的只有1个⼈，那么就可以建⼀个前缀索引，就是王。语法：
Index `index_name` (`index_field`(N))使⽤index_name前N个字符建⽴的索引。
那么N究竟是多少？使⽤N长度所达到的辨识度，极限接近于使⽤全部长度的辨识度即可！先计算最⼤的辨识度M：
公式：先计算总的记录数m，再求该字段不重复的记录数q，那么M=m/q。然后依次取得前N个字符，N逐步增加，进⾏对⽐，直到找到极限接近于M的，那么最后的N就是我们要找的N。
求得辨识度为1.4774.，也就是说⼀个前缀索引可以对应1.4774条记录。然后依次取得前N个字符，进⾏对⽐，找到极限接近的：
可见，9 时，已经极限接近，提⾼长度，不能明显提升辨识度，因此可以使⽤前9个字符：Tip：前缀索引不能⽤于索引覆盖！7.全⽂索引
该类型的索引特殊在：关键字的创建上。是为了解决 like‘%keyword%’这类查询的匹配问题。（mysql的全⽂索引⼏乎不⽤，因为它不⽀持中⽂，我们应该使⽤sphinx全⽂索引）。⽰例：
假如有⼀张表，表中有标题和内容两个字段，现在要查询标题或者内容包含 “database” 关键字的记录。补充：text和varchar的区别是text的数据不存在记录⾥，⼀条记录的最⼤空间是65535.
形成的SQL如下：
Select * from articles where title like ‘%database%’ or body like ‘%database%’;此时不能建⽴普通索引，查询不符合左原则，建⽴了也使⽤不了。此时全⽂索引就可以发挥其作⽤了：
直接使⽤上⾯的SQL，需要使⽤特殊的全⽂索引匹配语法才可以⽣效： Match() against();
Tip: 该MYSQL提供的全⽂索引，不能对中⽂起作⽤！
使⽤Match() against() 返回关键字的匹配度（关键字与记录的关联程度）。
停⽌词 in：
发现in这个词，是不能被全⽂索引所检索到的。因为in这个词是不可以⽤在全⽂索引的关键词⾥的，没有谁会在⼀段⽂本⾥检索这样⼀个词。
思考：与 like %in% 是否相同？不同。
原因何在呢？全⽂索引，索引的的关键字，不是整个字段数据，⽽是从数据中提取的关键词。8.索引结构-b-tree介绍
Hash、B-Tree（B树）两种数据结构。指的是mysql存储索引所采⽤的数据结构。其中，⽤户所维护的所有的索引结构 B-Tree结构。B-Tree的结构如下：
每个节点，存储多个关键字。关键字也会对应记录地址
以上设计为了解决⼀次性磁盘IO开销，可以读取到更多的关键字数量。每个关键字之间，存在⼦节点指针：
如果是复合索引：
关键字的排序先排左侧字段，在左侧字段相同的情况下，再排序右侧字段：9.聚集索引(聚簇索引)B+Tree(B-Tree的变种)
在innodb的存储引擎上，主键索引是与数据记录存储在⼀起的（聚簇在⼀起的）。
带来的问题：
Innodb的其他索引，⾮主键索引（⼆级索引）：关键字对应的不再是记录的地址，⽽是记录的主键。
可见，检索需要⼆次检索。先检索到主键ID，再检索记录。
五、查询缓存query_cache
将select的结果，存取起来共⼆次使⽤的缓存区域：
MySQL提供的缓存区：未开启前：
两次查询时间消耗⼀致。开启查询缓存，通过变量控制：
开启并设置⼤⼩：
再次执⾏查询：
可见，第⼆次查询，使⽤了开启的缓存！
注意事项：查询缓存存在判断是严格依赖于select语句本⾝的：严格保证SQL⼀致。
如果查询时包含动态数据，则不能被缓存。
⼀旦开启查询缓存，MySQL会将所有可以被缓存的select语句都缓存。如果存在不想使⽤缓存的SQL执⾏，则可以使⽤ SQL_NO_CACHE语法提⽰达到⽬的：
注意：这⾥的缓存仅当数据表的记录改变时，缓存才会被删除。⽽不是依靠过期时间的。六、分区分表
⽇常开发中我们经常会遇到⼤表的情况，所谓的⼤表是指存储了百万级乃⾄千万级条记录的表。这样的表过于庞⼤，导致在查询和插⼊的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的⽬的就是减少数据库的负担，提⾼数据库的效率，通常点来讲就是提⾼表的增删改查效率。
分区，partition，分区是将数据分段划分在多个位置存放，可以是同⼀块磁盘也可以在不同的机器。分区后，表⾯上还是⼀张表，但数据散列到多个位置了。app读写的时候操作的还是⼤表名字，db⾃动去组织分区的数据。
其实每个分区，就是独⽴的表。都要存储该分区数据的数据，索引等信息。创建分区：在创建表时，指定分区的选项：Create table table_name (定义)Partition by 分区算法 (参数) 分区选项。例如：Partition by key (id) partitions 5;
采⽤key取余算法，根据id的值进⾏取余，即对5取余，然后分配到5个区⾥。分区结果如下：myisam下
Innodb下
Tip：分区与存储引擎⽆关，是MySQL逻辑层完成的。可以通过变量查看当前mysql是否⽀持分区：
1.分区算法
MySQL提供4种分区算法：取余：Key，hash 条件：List，range 。参与分区的参数字段需要为主键的⼀部分。（1）KEY – 取余 ，按照某个字段进⾏取余
分成5个区，就是对5取余。将id对5取余。
（2）Hash – 取余，按照某个表达式的值进⾏取余⽰例：学⽣表分区，按照⽣⽇的⽉份，划分到12个表中。
注意：Key，hash都是取余算法，要求分区参数（括号⾥的），返回的数据必须为整数。（3）List – 条件 – 列表，需要指定的每个分区数据的存储条件。⽰例：按照⽣⽇中的⽉份，分成春夏秋冬四个分区。
List，条件依赖的数据是列表形式。
（4）Range - 条件 – 范围， 条件依赖的数据是⼀个条件表达式。逻辑：按照⽣⽇的年份分成不同的年龄段。
2.分区的管理与选择（1）取余：key，hash
增加分区数量： add partition partitions N
减少分区数量： COALESCE partition N
采⽤取余算法的分区数量的修改，不会导致已有分区数据的丢失，因为会重新分配数据到新的分区。（2）条件：list，range添加分区
删除分区：
Drop partition partition_name;
注意：删除条件算法的分区，会导致分区数据丢失。添加分区不会。（3）选择分区算法
平均分配：就按照主键进⾏key(primary key)即可(⾮常常见)按照某种业务逻辑分区：选择那种最容易被筛选的字段，整数型3.分表
分表是将⼀个⼤表按照⼀定的规则分解成多张具有独⽴存储空间的实体表，我们可以称为⼦表，每个表都对应三个⽂件，MYD数据⽂
件，.MYI索引⽂件，.frm表结构⽂件。这些⼦表可以分布在同⼀块磁盘上，也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的⼦表名，然后去操作它。分表技术是⽐较⿇烦的，需要⼿动去创建⼦表，app服务端读写时候需要计算⼦表名。采⽤merge好⼀些，但也要创建⼦表和配置⼦表间的union关系。（需要⼿动分表）
分表是分区之前⽤的，MYSQL5.1后，就开始⽤分区代替分表了。分表很少⽤了。（1）⽔平分表
创建结构相同的N个表；
再创建⽤于管理学⽣ID的表student_id：(该表是为了提供⾃增的ID)
客户端逻辑：
Merge，mrg_myisam
是MySQL提供⼀个可以将多个结构相同的myisam表，合并到⼀起的存储引擎：
（2）垂直分表
⼀张表中存在多个字段。这些字段可以分为常⽤字段和⾮常⽤字段，为了提⾼查表速度，我们可以把这两类字段分开来存储。主要⽬的，减少每条记录的长度。
通常我们按以下原则进⾏垂直拆分:把不常⽤的字段单独放在⼀张表;把text，blog等⼤字段拆分出来放在附表中;经常组合查询的列放在⼀张表中;
例如学⽣表可以分成：
基础表(Student_base)和额外表(Student_extra)，两张表中记录为1:1的关系。基础信息表Student_baseId name age
额外信息表Student_extraId 籍贯 政治⾯貌七、服务器架构介绍
服务器架构，不仅仅是⽤⼀台MySQL主从复制：
Mysql服务器内部⽀持复制功能，仅仅需要通过配置完成下⾯的拓扑结构。⼀主多从典型结果：主服务器负责写数据。从服务器负责读数据。复制功能mysql会⾃带。
读写分离，负载均衡：
php不再操作MYSQL数据库服务器，⽽是去操作读写分离、负载均衡服务器，只要服务器安装了mysql proxy或Ameoba软件就可以实现读写分离和负载均衡，读写分离是指该服务器会判断客户端的操作是读还是写，从⽽选择操作mysql主服务器还是从服务器。负载均衡算法是指，客户端读操作时，该服务器会根据取余算法去选择⼀台从服务器。
上⾯的架构可以提升整体服务器的效率，⾼性能。
同时，服务器架构需要保证，⾼可⽤（稳定），7x24不宕机。因此需要增加⼀些冗余服务器以便备⽤。时时检测正在⽤的服务器。
⼋、SQL优化1.对于并发性的SQL
少⽤（不⽤）多表操作（⼦查询，联合查询），⽽是将复杂的SQL拆分多次执⾏。如果查询很原⼦（很⼩），会增加查询缓存的利⽤率。2.⼤量数据的插⼊
多条 insert或者Load data into table（从⽂件⾥载⼊数据到表⾥）建议，先关闭约束及索引，完成数据插⼊，再重新⽣成索引及约束。针对于myisam，步骤：
Alter table table_name disable keys; 禁⽤索引约束⼤量的插⼊
Alter table table_name enable keys; 启⽤针对innodb，步骤：
Drop index, drop constraint 删除索引及约束，要保留主键Begin transaction|set autocommit=0; 开启事务，不让他⾃动提交[数据本⾝已经按照主键值排序]⼤量的插⼊Commit;
Add index, add constraint3.分页
分页假定Limit offset, size; size = 10;Page5505000
offset40, 10490, 104990, 10
500000499990, 10
Limit 的使⽤，会⼤⼤提升⽆效数据的检索（被跳过），因为是先检索，检索会检索全部，再取得想要的。好的做法是使⽤条件等过滤⽅式，将检索到的数据尽可能精确定位到需要的数据上。4.随机选⼀些数据，不要使⽤Order by Rand()
上⾯的查询，会导致每条记录都执⾏rand()，成本很⾼！
建议，通过mt_rand()，先确定的随机主键，再从数据表中获取数据。九、慢查询⽇志的使⽤定位执⾏较慢的查询语句⽅案。
show variables like 'slow_query%'; show variables like '%long_query%';
Slow_query_log = 0|1
Long_query_time = N 超过该时间临界点，就为慢查询。开启⽇志
set global slow_query_log=1; set long_query_time=0.5；
执⾏SQL，查看：
因篇幅问题不能全部显示，请点此查看更多更全内容