MySQL优化

--查看整个数据库服务的线程数show global status like 'Thread%';--刷新会话级别的计数器FLUSH STATUS--查看当前会话的状态信息SHOW STATUS--查看所表参数信息SHOW  TABLE STATUS--查看连接信息SHOW  PROCESSLIST--开启会话级别的profileSET profiling=1--查看所有的数据库操作执行过程SHOW PROFILES--查询单条语句profileSHOW PROFILE FOR QUERY 1--查看当前被锁住的表show OPEN TABLES where In_use > 0;

---

一、mysql 索引优化

1):单表数据百万量级,记录分页性能如何优化。
limit 查询语句的查询时间是和起始记录的位置成正比。
解决方法:利用表的覆盖索引、查询索引
自增的id是主键索引。

select id from product limit 866613, 20

那么如果我们也要查询所有列，有两种方法，一种是id>=的形式，另一种就是利用join，看下实际情况：

SELECT * FROM product WHERE ID > =(select id from product limit 866613, 1) limit 20

查询时间为0.2秒，简直是一个质的飞跃啊，哈哈
2):mysql 组合索引
有组合查询的sql,尽量建立组合索引。
组合索引遵循最左优先原则:
组合索引的第一个字段必须出现在查询组句中，这个索引才会被用到。
下面情况都会用到索引
例如:order_index(a,b,c)

  where a=1,b=2,c=3;    where a=1,c=3;  where a=1,b=3;

下面情况不会用到索引

  where b=2,a=1;  where c=2,a=1;  where b=1,c=2;

3):mysql like 的查询优化;
1000万数据使用like 效率太低。

select tag from log where tag like '%www.%'; - 此SQL效率查询低下

——替代sql —————-

  select tag from log where  instr('tag','www.') >0;  select tag from log where  locate('tag','www.') >0;

也可以根据表结果使用find_in_set 对于 字段是用逗号分隔开

  select * from tags where find_in_set('xiaow',tag); 

4):mysql where like 语句是否能用到索引:

  EXPLAIN select * from tags where tag like 'abc%'; 可以用到索引  EXPLAIN select * from tags where tag like '%abc'; 可以用到索引  EXPLAIN select * from tags where tag like '%abc%';不能用到索引

二、mysql(insert、update 、delete) 优化

1)insert 优化:
如果同时从同一个客户端插入很多行，使用含多个VALUE的INSERT语句同时插入几行。这比使用单行INSERT语句快(在某些情况下快几倍)。
例如:INSERT INTO a VALUES (1,23),(2,34),(4,33);
bulk_insert_buffer_size 修改次参数

---

MySQL介绍：

MySQL是一个开放源代码的关系数据库管理系统。原开发者为瑞典的MySQL AB公司，最早是在2001年MySQL3.23进入到管理员的视野并在之后获得广泛的应用。2008年MySQL公司被Sun公司收购并发布了首个收购之后的版本MySQL5.1，该版本引入分区、基于行复制以及plugin API。移除了原有的BerkeyDB引擎，同时，Oracle收购InnoDB Oy发布了InnoDB plugin，这后来发展成为著名的InnoDB引擎。2010年Oracle收购Sun公司，这也使得MySQL归入Oracle门下，之后Oracle发布了收购以后的首个版本5.5，该版本主要改善集中在性能、扩展性、复制、分区以及对windows的支持。目前版本已发展到5.7。
和其它数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

MySQL存储引擎：

InnoDB引擎：

    1.将数据存储在表空间中，表空间由一系列的数据文件组成，由InnoDB管理；    2.支持每个表的数据和索引存放在单独文件中(innodb_file_per_table)；    3.支持事务，采用MVCC来控制并发，并实现标准的4个事务隔离级别，支持外键；    4.索引基于聚簇索引建立，对于主键查询有较高性能；    5.数据文件的平台无关性，支持数据在不同的架构平台移植；    6.能够通过一些工具支持真正的热备。如XtraBackup等；    7.内部进行自身优化如采取可预测性预读，能够自动在内存中创建hash索引等。

MyISAM引擎：

    1.MySQL5.1中默认，不支持事务和行级锁；    2.提供大量特性如全文索引、空间函数、压缩、延迟更新等；    3.数据库故障后，安全恢复性差；    4.对于只读数据可以忍受故障恢复，MyISAM依然非常适用；    5.日志服务器的场景也比较适用，只需插入和数据读取操作；    6.不支持单表一个文件，会将所有的数据和索引内容分别存在两个文件中；    7.MyISAM对整张表加锁而不是对行，所以不适用写操作比较多的场景；    8.支持索引缓存不支持数据缓存。

Archive引擎：

    1.只支持insert和select操作；    2.缓存所有的写数据并进行压缩存储，支持行级锁但不支持事务；    3.适合高速插入和数据压缩，减少IO操作，适用于日志记录和归档服务器。

Blackhole引擎：

    1.没有实现任何存储机制，会将插入的数据进行丢弃，但会存储二进制日志；    2.会在一些特殊需要的复制架构的环境中使用。

CSV引擎：

    1.可以打开CSV文件存储的数据，可以将存储的数据导出，并利用excel打开；    2.可以作为一种数据交换的机制，同样经常使用。

Memory引擎：

    1.将数据在内存中缓存，不消耗IO；    2.存储数据速度较快但不会被保留，一般作为临时表的存储被使用。

Federated引擎：

    能够访问远程服务器上的数据的存储引擎。能够建立一个连接连到远程服务器。

Mrg_MyISAM引擎：

    将多个MYISAM表合并为一个。本身并不存储数据，数据存在MyISAM表中间。NDB集群引擎：    MySQL Cluster专用。

MySQL第三方存储引擎：

1.OLTP类：    XtraDB：InnoDB的改进版本。    PBXT：类似InnoDB，但提供引擎级别的复制和外键约束，适当支持SSD存储。    TokuDB(开源)：支持分形树索引结构，支持海量数据的分析。2.列式存储引擎：MySQL默认是面向行的存储。    Infobright：支持数十TB的数据量，为数据分析和数据仓库设计的。数据高度压缩。    InfiniDB：可以在一组集群间做分布式查询，有商业版但没有典型应用案例。3.社区存储引擎：    Aria：解决MyISAM崩溃安全恢复问题，并能够进行数据缓存。    Groona：全文索引引擎。    QQGraph：由Open query研发支持图操作，比如查找两点间最短距离。    SphinxSE：该引擎为Sphinx全文索引搜索服务器提供SQL接口。    Spider：支持sharding并能够基于分片实现并列查询。    VPForMySQL：支持垂直分区。

MySQL存储引擎选取参考因素：

1.是否有事务需求    如果需要事务支持最好选择InnoDB或者XtraDB，如果主要是select和insert操作MyISAM比较合适，一般使用日志型的应用。2.备份操作需求    如果能够关闭服务器进行备份，那么该因素可以忽略，如果需要在线进行热备份，则InnoDB引擎是一个不错的选择。3.故障恢复需求    在对恢复要求比较好的场景中推荐使用InnoDB，因为MyISAM数据损坏概率比较大而且恢复速度比较慢。4.性能上的需求    有些业务需求只有某些特定的存储引擎才能够满足，如地理空间索引也只有MyISAM引擎支持。所以在应用架构需求环境中也需要管理员折衷考虑，当然从各方面比较而言，InnoDB引擎还是默认应该被推荐使用的。

关系型数据库：是建立在关系模型基础上的数据库，关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。关系模型就是指二维表格模型，因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。关系型数据库简单的可以理解为二维数据库，表的格式就如Excel，有行有列。
主流数据库：Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL；

非关系型数据库：随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。
主流数据库：Redis、Tokyo Cabinet、Flare、MongoDB、CouchDB、Cassandra、Voldemort；

NoSQL的四大分类：

    1、键值(Key-Value)存储数据库。        数据模型：Key指向Value的键值对，通常用hash table来实现；        典型应用场景：内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等；        优点：查找速度快；        缺点：数据无结构化，通常只被当作字符串或者二进制数据；        举例：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB；    2、列存储数据库。        数据模型：以列簇式存储，将同一列数据存在一起；        典型应用场景：分布式的文件系统；        优点：查找速度快，可扩展性强，更容易进行分布式扩展；        缺点：功能相对局限；        举例：Cassandra, HBase, Riak；    3、文档型数据库。        数据模型：Key-Value对应的键值对，Value为结构化数据；        典型应用场景：Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）；        优点：数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构；        缺点：查询性能不高，而且缺乏统一的查询语法；        举例：CouchDB, MongoDb；    4、图形(Graph)数据库。        数据模型：图形结构；        典型应用场景：社交网络，推荐系统等。专注于构建关系图谱；        优点：利用图结构相关算法。比如最短路径寻址，N度关系查找等；        缺点：很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案；        举例：Neo4J, InfoGrid, Infinite Graph；关系型数据库暴露的问题：    对数据库高并发读写的需求    对海量数据的高效率存储和访问的需求    对数据库的高可扩展性和高可用性的需求NoSQL解决关系型数据暴露的问题：    满足极高读写性能需求的Key-Value数据库：Redis，Tokyo Cabinet，Flare；    满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB；    满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort；

关系型数据库/非关系型数据库：

关系型数据库：    优点：        1、事务支持（保持数据的一致性）；        2、可以进行Join等复杂查询；        3、由于以标准化为前提，数据更新的开销很小（相同的字段基本上都只有一处）；    缺点：        1、关系数据库所采用的二维表格数据模型不能有效地处理多维数据，不能有效处理互联网应用中半结构化和非结构化的海量数据，如Web页面、电子邮件、音频、视频等。        2、高并发读写的性能低。            关系数据库达到一定规模时，非常容易发生死锁等并发问题，导致其读写性能下降非常严重。            Web2.0网站数据库并发负载非常高，往往要达到每秒上万次读写请求。            关系型数据库勉强可以应付上万次SQL查询，但硬盘I/O往往无法承担上万次的SQL写数据请求。        3、支撑容量有限。            类似人人网，新浪微博，Facebook，Twitter，Friendfeed（已被Facebook收购）这样的网站，每天用户产生海量的用户动态信息。            a、以Facebook为例，一个月就要存储1350亿条（未得到确认）用户动态，对于关系数据库来说，在一张1350亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。            b、再例如大型Web网站或IM的用户登录系统，例如腾讯，MSN，动辄数以亿计的帐号，关系数据库也很难应付。        4、数据库的可扩展性和可用性低。            当一个应用系统的用户量和访问量与日俱增的时候，传统的关系型数据库却没有办法像Web Server那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。            对于很多需要提供不间断服务的系统来说，对数据库系统进行升级和扩展往往需要停机维护和数据迁移。非关系型数据库：    优点：        1、查询速度快。NoSQL数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及NoSQL数据库。        2、高性能。NoSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。        3、高扩展性。因为基于键值对，数据之间没有耦合性，所以扩展性强。        4、成本低。NoSQL数据库简单易部署，基本都是开源软件，不需要像使用Oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。        5、存储数据的格式。NoSQL的存储格式是Key，Value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。    缺点：        1、不支持事务（弱一致性）；        2、不提供对SQL的支持，如果不支持SQL这样的工业标准，将产生一定用户的学习和使用成本。        3、维护的工具和资料有限，因为NoSQL是属于新的技术，不能和关系型数据库10几年的技术同日而语。

数据库设计三大范式：

1、第一范式(确保每列保持原子性)；2、第二范式(确保表中的每列都和主键相关)；3、第三范式(确保每列都和主键列直接相关,而不是间接相关)；

数据库事务的四大特性（ACID）：

原子性（Atomicity）：    事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。一致性（Consistemcy）：    事务前后，数据库的状态都满足所有的完整性约束。隔离性（Isolation）：    并发执行的事务是隔离的，一个不影响一个。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。通过设置数据库的隔离级别，可以达到不同的隔离效果。持久性（Durability）：    在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

并发事务引起的问题：

更新丢失：    两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。脏读：    脏读又称无效数据读出。一个事务读取另外一个事务还没有提交的数据叫脏读。例如：事务T1修改了一行数据，但是还没有提交，这时候事务T2读取了被事务T1修改后的数据，之后事务T1因为某种原因Rollback了，那么事务T2读取的数据就是脏的。不可重复读：    不可重复读是指在同一个事务内，两个相同的查询返回了不同的结果。例如：事务T1读取某一数据，事务T2读取并修改了该数据，T1为了对读取值进行检验而再次读取该数据，便得到了不同的结果。幻读：    事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据。例如：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样。这就叫幻读。

事务的隔离级别：以上的4种问题（更新丢失、脏读、不可重复读、幻读）都和事务的隔离级别有关。通过设置事务的隔离级别，可以避免上述问题的发生。
1、未授权读取级别：
也称为读未提交（Read Uncommitted）。
以操作同一行数据为前提，读事务允许其他读事务和写事务，未提交的写事务禁止其他写事务（但允许其他读事务）。
此隔离级别可以防止更新丢失，但不能防止脏读、不可重复读、幻读。
此隔离级别可以通过“排他写锁”实现。
2、授权读取级别：
也称为读提交（Read Committed）。
以操作同一行数据为前提，读事务允许其他读事务和写事务，未提交的写事务禁止其他读事务和写事务。
此隔离级别可以防止更新丢失、脏读，但不能防止不可重复读、幻读。
此隔离级别可以通过“瞬间共享读锁”和“排他写锁”实现。
3、可重复读取级别：
可重复读取（Repeatable Read）。
以操作同一行数据为前提，读事务禁止其他写事务（但允许其他读事务），未提交的写事务禁止其他读事务和写事务。
此隔离级别可以防止更新丢失、脏读、不可重复读，但不能防止幻读。
此隔离级别可以通过“共享读锁”和“排他写锁”实现。
4、序列化级别：
序列化（Serializable）。
提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。
此隔离级别可以防止更新丢失、脏读、不可重复读、幻读。
如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
注意：隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免更新丢失、脏读，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

定义事务的SQL语句：
BEGIN TRANSACTION 事务名 /标记一个显式本地事务的起始点/
COMMIT TRAN 事务名 /提交事务/
ROLLBACK TRAN 事务名 /回滚事务/

数据库的锁：

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好。表级锁：对整个表加锁。引擎 MyISAM。表级锁有两种模式：表共享读锁和表独占写锁。    表共享读锁：对MyISAM表进行读操作时，它不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写操作；    表独占写锁：对MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作；行级锁：对一行记录加锁。引擎 INNODB。行级锁有两种模式：共享锁和排他锁。    共享锁：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。    排他锁：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。    注意：为了允许行锁和表锁共存，实现多粒度锁机制；同时还有两种内部使用的意向锁（都是表锁），分别为意向共享锁和意向排他锁。        InnoDB行锁是通过给索引项加锁来实现的，即只有通过索引条件检索数据，InnoDB才使用行级锁，否则将使用表锁！页级锁：对相邻的一组记录加锁。引擎 BDB。以上三种锁的特性：    表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。    行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。    页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

MySQL索引：

概念：官方介绍索引是帮助MySQL高效获取数据的数据结构，也可以理解索引相当于一本书的目录，通过目录能够快速的定位并且查找到内容。通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。索引结构：B-Tree/B+Tree、Hash；常见索引：    唯一索引：强调唯一，就是索引值必须唯一。        创建索引：        create unique index 索引名 on 表名(列名);        alter table 表名 add unique index 索引名(列名);        删除索引：        drop index 索引名 on 表名;        alter table 表名 drop index 索引名;    主键：主键就是唯一索引的一种，主键要求建表时指定，一般用auto_increment列，关键字是primary key。        主键创建：        creat table test (id int not null primary key auto_increment);    全文索引：InnoDB不支持，MyISAM支持性能比较好，一般在 CHAR、VARCHAR 或 TEXT 列上创建。        create table 表名(            id int not null primary key anto_increment,            title varchar(100), FULLTEXT(title)        ) type=MyISAM;    单列索引与多列索引：索引可以是单列索引也可以是多列索引（也叫复合索引）。        create table test(            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)的索引来使用，这是一个最左前缀的优化方法。        最左前缀：顾名思义，就是最左优先，上例中我们创建了lname_fname_age多列索引，相当于创建了(lname)单列索引，(lname, fname)组合索引以及(lname, fname, age)组合索引。    聚簇索引：一种索引，该索引中键值的逻辑顺序决定了表中相应行的物理顺序。聚集索引确定表中数据的物理顺序。MySQL中MyISAM表是没有聚集索引的，InnoDB有（主键就是聚集索引）。InnoDB按照主键进行聚集，如果没有定义主键，InnoDB会试着使用唯一的非空索引来代替。如果没有这种索引，InnoDB就会定义隐藏的主键然后在上面进行聚集。所以，对于聚集索引来说，你创建主键的时候，自动就创建了主键的聚集索引。B-Tree和B+Tree：    B-Tree，B是Balance，一般用于数据库的索引。使用B-Tree结构可以显著减少定位记录时所经历的中间过程，从而加快存取速度。而B+Tree是B-Tree的一个变种，MySQL就普遍使用B+Tree实现其索引结构。    数据库使用这种结构的原因：        一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。        为了达到这个目的，磁盘按需读取，要求每次都会预读的长度一般为页的整数倍。而且数据库系统将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个Node只需一次I/O。并把B-Tree中的m值设的非常大，就会让树的高度降低，有利于一次完全载入。    B-Tree的特性：        1.关键字集合分布在整颗树中；        2.任何一个关键字出现且只出现在一个结点中；        3.搜索有可能在非叶子结点结束；        4.其搜索性能等价于在关键字全集内做一次二分查找；        5.自动层次控制；    B+Tree的特性：        1.所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好是有序的；        2.不可能在非叶子结点命中；        3.非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储（关键字）数据的数据层；        4.更适合文件索引系统；    MyISAM索引与InnoDB索引区别：        MyISAM支持全文索引（FULLTEXT）、压缩索引，InnoDB不支持。        InnoDB支持事务，MyISAM不支持。        MyISAM顺序储存数据，索引叶子节点保存对应数据行地址，辅助索引和主键索引相差无几；InnoDB主键节点同时保存数据行，其他辅助索引保存的是主键索引的值。        MyISAM键值分离，索引载入内存（key_buffer_size），数据缓存依赖操作系统；InnoDB键值一起保存，索引与数据一起载入InnoDB缓冲池。        MyISAM主键（唯一）索引按升序来存储，InnoDB则不一定。        MyISAM处理字符串索引时用增量保存的方式，如第一个索引是‘preform’，第二个是‘preformence’，则第二个保存是‘7，ance‘，这个明显的好处是缩短索引，但是缺陷就是不支持倒序提取索引，必须顺序遍历获取索引。

MySQL主从同步/读写分离：

原理：主服务器（master）将数据更改的记录写入二进制日志文件（binary log），并维护文件的一个索引以跟踪日志循环。从服务器（slave）的IO线程从主服务器获取二进制日志，并在本地保存为中继日志，然后通过SQL线程来再从上执行中继日志中的内容，从而使从库和主库保持一致。技术特点：数据分布、负载平衡、备份、高可用性和容错；配置步骤：    主从同步环境介绍；    在主服务器上建立同步帐号；    从服务器配置文件的更改；    从主服务器得到一个快照版本；    将快照版本还原到从服务器上；    在从服务器上使用change master从主服务器上同步；读写分离：MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。当然，主服务器也可以提供查询服务。使用读写分离最大的作用无非是环境服务器压力。

MySQL分表：是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表，我们可以称为子表，每个表都对应三个文件，MYD数据文件，MYI索引文件，FRM表结构文件。这些子表可以分布在同一块磁盘上，也可以在不同的机器上。应用程序读写的时候根据事先定义好的规则得到对应的子表名，然后去操作它。
分表的原因：日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。
分表的方式：
1、MySQL集群；
2、自定义规则分表；
3、Merge存储引擎实现分表；

MySQL集群：同步集群和异步集群；
同步集群（mysql cluster）
结构：（data + sql + mgm 节点）
特点：
1、内存级别的，对硬件要求较低，但是对内存要求较大。换算比例为：1：1.1；
2、数据同时放在几台服务器上，冗余较好；
3、速度一般；
4、建表需要声明为engine=ndbcluster；
5、扩展性强；
6、可以实现高可用性和负载均衡，实现对大型应用的支持；
7、必须是特定的mysql版本，如：已经编译好的max版本；
8、配置和管理方便，不会丢失数据；
异步集群（mysql replication）
结构：（master + slave）
特点：
1、主从数据库异步数据；
2、数据放在几台服务器上，冗余一般；
3、速度较快；
4、扩展性差；
5、无法实现高可用性和负载均衡（只能在程序级别实现读写分离，减轻对主数据库的压力）；
6、配置和管理较差，可能会丢失数据；