数据库优化资料

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明：

一、数据库设计

适度的反范式,注意是适度的

我们都知道三范式，基于三范式建立的模型是最有效保存数据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：

在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000 ，导致更新一个单位名称还要更新4000条冗余记录。由此可见，这个冗余根本就是适得其反。

下面这个冗余就很好

可以看到，[学生考试总分]是冗余的，这个分数完全可以通过[得分情况]汇总得到。在【学生考试总分】里，一次考试一个学生只有一条记录，而在【得分情况】里，一个学生针对试卷里一个小题的一个小问一条记录，粗略的算一下比例大概是1：100。而且判卷子得分是不会轻易变的，更新的频率不高，所以说这个冗余是比较好的。

适当建立索引

说起提高数据库性能，索引是最物美价廉的东西了。不用加内存，不用改程序，不用调sql，只要执行个正确的’create index’，查询速度就可能提高百倍千倍，这可真有诱惑力。可是天下没有免费的午餐，查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的I/O。由于索引的存储结构不同于表的存储，一个表的索引所占空间比数据所占空间还大的情况经常发生。这意味着我们在写数据库的时候做了很多额外的工作，而这个工作只是为了提高读的效率。因此，我们建立一个索引，必须保证这个索引不会“亏本”。一般需要遵守这样的规则：索引的字段必须是经常作为查询条件的字段;

如果索引多个字段，第一个字段要是经常作为查询条件的。如果只有第二个字段作为查询条件，这个索引不会起到作用;

索引的字段必须有足够的区分度;

Mysql 对于长字段支持前缀索引;

对表进行水平划分

如果一个表的记录数太多了，比如上千万条，而且需要经常检索，那么我们就有必要化整为零了。如果我拆成100个表，那么每个表只有10万条记录。当然这需要数据在逻辑上可以划分。一个好的划分依据，有利于程序的简单实现，也可以充分利用水平分表的优势。比如系统界面上只提供按月查询的功能，那么把表按月拆分成12个，每个查询只查询一个表就够了。如果非要按照地域来分，即使把表拆的再小，查询还是要联合所有表来查，还不如不拆了。所以一个好的拆分依据是最重要的。

这里有个比较好的实例

每个学生做过的题都记录在这个表里，包括对题和错题。每个题会对应一个或多个知识点，我们需要根据错题来分析学生在哪个知识点上掌握的不足。这个表很容易达到千万级，迫切需要拆分，那么根据什么来拆呢?从需求上看，无论是老师还是学生，最终会把焦点落在一个学生的身上。学生会关心自己，老师会关心自己班的学生。而且每个学科的知识点是不同的。所以我们很容易想到，联合学科和知识点两个字段来拆分这个表。这样拆下来，每个表大概2万条数据，检索效率非常高。

对表进行垂直划分

有些表记录数并不多，可能也就2、3万条，但是字段却很长，表占用空间很大，检索表时需要执行大量I/O，严重降低了性能。这个时候需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。

【试题内容】、【答案信息】两个表，最初是作为几个字段添加到【试题信息】里的，可以看到试题内容和答案这两个字段很长，在表里有3万记录时，表已经占了1G的空间，在列试题列表时非常慢。经过分析，发现系统很多时候是根据【册】、【单元】、类型、类别、难易程度等查询条件，分页显示试题详细内容。而每次检索都是这几个表做join，每次要扫描一遍1G的表，很郁闷啊。我们完全可以把内容和答案拆分成另一个表，只有显示详细内容的时候才读这个大表，由此就产生了【试题内容】、【答案信息】两个表。

选择适当的字段类型，特别是主键

选择字段的一般原则是保小不保大，能用占用字节小的字段就不用大字段。比如主键，我们强烈建议用自增类型，不用guid，为什么?省空间啊?空间是什么?空间就是效率!按4个字节和按32个字节定位一条记录，谁快谁慢太明显了。涉及到几个表做join时，效果就更明显了。值得一提的是，datetime和timestamp，datetime占用8个字节，而timestamp 占用4 个字节，只用了一半，而timestamp表示的范围是1970—2037，对于大多数应用，尤其是记录什么考试时间，登录时间这类信息，绰绰有余啊。

文件、图片等大文件用文件系统存储，不用数据库

不用多说，铁律!!!数据库只存储路径。

外键表示清楚，方便建立索引

我们都知道，在powerdesigner里为两个实体建立关系，生成物理模型时会自动给外键建立索引。所以我们不要怕建立关系把线拉乱，建立个ShortCut就好了。

掌握表的写入时机

在库模式相同的情况下，如何使用数据库也对性能有着重要作用。同样是写入一个表，先写和后写对后续的操作会产生很大影响。例如在上面提到的适度冗余里的例子，

我们最初的目的是记录考生的总分，以达到提高检索效率的目的，也就是在录入成绩时写入这个表。在需求里有这样的要求：列出本次考试的所有学生成绩，没有录入成绩的也显示该学生名称，只是总分显示为空。这个查询就需

这还只是个中间过程，这要是用程序实时处理，即使编程人员不罢工，数据库也会歇了。

选择合适的引擎

Mysql提供了很多种引擎，我们用的最多的是myisam，innodb，memory这三类。官方手册上说道myisqm比innodb 的读速度要快，大概是3倍。不过书不能尽信啊，《OreIlly.High.Performance.Mysql》这本书里提到了myisam和innodb 的比较，在测试中myisam的表现还不及innodb。至于memory，哈哈，还是比较好用的。在批处理种作临时表是个不错的选择(如果内存够大)。在我的一个批处理中，速度比近乎1：10。

二、SQL语句优化

Sql语句优化工具

·慢日志

如果发现系统慢了，又说不清楚是哪里慢，那么就该用这个工具了。只需要为mysql配置参数，mysql会自己记录下来慢的sql语句。配置很简单，参数文件里配置：

slow_query_log=d:/slow.txt

long_query_time = 2

就可以在d:/slow.txt里找到执行时间超过2秒的语句了，根据这个文件定位问题吧。

·mysqldumpslow.pl

慢日志文件可能会很大，让人去看是很难受的事。这时候我们可以通过mysql自带的工具来分析。这个工具可以格式化慢日志文件，对于只是参数不同的语句会归类类并，比如有两个语句select * from a where id=1 和select * from a where id=2，经过这个工具整理后就只剩下select * from a where id=N，这样读起来就舒服多了。而且这个工具可以实现简单的排序，让我们有的放矢。

Explain

现在我们已经知道是哪个语句慢了，那么它为什么慢呢?看看mysql是怎么执行的吧，用explain可以看到mysql执行计划，下面的用法来源于手册

EXPLAIN语法(获取SELECT相关信息)

EXPLAIN [EXTENDED] SELECT select_options

EXPLAIN语句可以用作DESCRIBE的一个同义词，或获得关于MySQL如何执行SELECT语句的信息：

·EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。

·如果在SELECT语句前放上关键词EXPLAIN，MySQL将解释它如何处理SELECT，提供有关表如何联接和联接的次序。

该节解释EXPLAIN的第2个用法。

借助于EXPLAIN，可以知道什么时候必须为表加入索引以得到一个使用索引来寻找记录的更快的SELECT。

如果由于使用不正确的索引出现了问题，应运行ANALYZE TABLE更新表的统计(例如关键字集的势)，这样会影响优化器进行的选择。

还可以知道优化器是否以一个最佳次序联接表。为了强制优化器让一个SELECT语句按照表命名顺序的联接次序，语句应以STRAIGHT_JOIN而不只是SELECT开头。

EXPLAIN为用于SELECT语句中的每个表返回一行信息。表以它们在处理查询过程中将被MySQL读入的顺序被列出。MySQL用一遍扫描多次联接(single-sweep multi-join)的方式解决所有联接。这意味着MySQL从第一个表中读一行，然后找到在第二个表中的一个匹配行，然后在第3个表中等等。当所有的表处理完后，它输出选中的列并且返回表清单直到找到一个有更多的匹配行的表。从该表读入下一行并继续处理下一个表。

当使用EXTENDED关键字时，EXPLAIN产生附加信息，可以用SHOW WARNINGS浏览。该信息显示优化器限定SELECT语句中的表和列名，重写并且执行优化规则后SELECT语句是什么样子，并且还可能包括优化过程的其它注解。

如果什么都做不了，试试全索引扫描

如果一个语句实在不能优化了，那么还有一个方法可以试试：索引覆盖。

如果一个语句可以从索引上获取全部数据，就不需要通过索引再去读表，省了很多I/O。比如这样一个表

如果我要统计每个学生每道题的得分情况，我们除了要给每个表的主键外键建立索引，还要对【得分情况】的实际得分字段索引，这样，整个查询就可以从索引得到数据了。

三、数据库参数配置

最重要的参数就是内存，我们主要用的innodb引擎，所以下面两个参数调的很大

# Additional memory pool that is used by InnoDB to store metadata

# information. If InnoDB requires more memory for this purpose it will

# start to allocate it from the OS. As this is fast enough on most

# recent operating systems, you normally do not need to change this

# value. SHOW INNODB STATUS will display the current amount used.

innodb_additional_mem_pool_size = 64M

# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and

# row data. The bigger you set this the less disk I/O is needed to

# access data in tables. On a dedicated database server you may set this

# parameter up to 80% of the machine physical memory size. Do not set it

# too large, though, because competition of the physical memory may

# cause paging in the operating system. Note that on 32bit systems you

# might be limited to 2-3.5G of user level memory per process, so do not

# set it too high.

innodb_buffer_pool_size = 5G

对于myisam，需要调整key_buffer_size

当然调整参数还是要看状态，用show status语句可以看到当前状态，以决定改调整哪些参数

Cretated_tmp_disk_tables 增加tmp_table_size

Handler_read_key 高表示索引正确Handler_read_rnd高表示索引不正确

Key_reads/Key_read_requests 应小于0.01 计算缓存损失率，增加Key_buffer_size

Opentables/Open_tables 增加table_cache

select_full_join 没有实用索引的链接的数量。如果不为0，应该检查索引。

select_range_check 如果不为0，该检查表索引。

sort_merge_passes 排序算法已经执行的合并的数量。如果该值较大，应增加sort_buffer_size

table_locks_waited 不能立即获得的表的锁的次数，如果该值较高，应优化查询

Threads_created 创建用来处理连接的线程数。如果Threads_created较大，要增加thread_cache_size值。

缓存访问率的计算方法Threads_created/Connections。

四、合理的硬件资源和操作系统

如果你的机器内存超过4G，那么毋庸置疑应当采用64位操作系统和64位mysql

读写分离

如果数据库压力很大，一台机器支撑不了，那么可以用mysql复制实现多台机器同步，将数据库的压力分散。

Master

Slave1

Slave2

Slave3

主库master用来写入，slave1—slave3都用来做select，每个数据库分担的压力小了很多。

要实现这种方式，需要程序特别设计，写都操作master，读都操作slave，给程序开发带来了额外负担。当然目前已经有中间件来实现这个代理，对程序来读写哪些数据库是透明的。官方有个mysql-proxy，但是还是alpha版本的。新浪有个amobe for mysql，也可达到这个目的，结构如下

使用方法可以看amobe的手册。

优化细节

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在where 及order by 涉及的列上建立索引。

2.应尽量避免在where 子句中对字段进行null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，

Sql 代码: select id from t where num is null;

可以在num 上设置默认值0,确保表中num 列没有null 值，然后这样查询：

Sql 代码: select id from t where num=0;

3.应尽量避免在where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。可以在LIKE操作中使用索引的情形是指另一个操作数不是以通配符（%或者_）开头的情形。例如，“SELECT id FROM t WHERE col LIKE 'Mich%';”这个查询将使用索引，但“SELECT id FROM t WHERE col LIKE '%ike';”这个查询不会使用索引。

4.应尽量避免在where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，

Sql 代码: select id from t where num=10 or num=20;

可以这样查询：

Sql 代码: select id from t where num=10 union all select id from t where num=20;

5.in 和not in 也要慎用，否则会导致全表扫描，如：

Sql 代码: select id from t where num in(1,2,3);

对于连续的数值，能用between 就不要用in 了：

Sql 代码: select id from t where num between 1 and 3;

6.下面的查询也将导致全表扫描：

Sql 代码: select id from t where name like '%c%';

若要提高效率，可以考虑全文检索。

7.如果在where 子句中使用参数，也会导致全表扫描。因为SQL 只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

Sql 代码: select id from t where num=@num ;

可以改为强制查询使用索引：

Sql 代码: select id from t with(index(索引名)) where num=@num ;

8.应尽量避免在where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。

Sql 代码: select id from t where num/2=100;

可以这样查询：

Sql 代码: select id from t where num=100*2;

9.应尽量避免在where 子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

Sql 代码: select id from t where substring(name,1,3)='abc';#name 以abc 开头的id

应改为：

Sql 代码: select id from t where name like 'abc%';

10.不要在where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

12.不要写一些没有意义的查询，如需要生成一个空表结构：

Sql 代码: select col1,col2 into #t from t where 1=0;

这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：

Sql 代码: create table #t(…);

13.很多时候用exists 代替in 是一个好的选择：

Sql 代码: select num from a where num in(select num from b);

用下面的语句替换：

Sql 代码: select num from a where exists(select 1 from b where num=a.num);

14.并不是所有索引对查询都有效，SQL 是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL 查询可能不会去利用索引，如一表中有字段sex,male、female 几乎各一半，那么即使在sex 上建了索引也对查询效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相应的select 的效率，但同时也降低了insert 及update 的效率，因为insert 或update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6 个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

16.应尽可能的避免更新clustered 索引数据列，因为clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新clustered 索引数据列，那么需要考虑是否应将该索引建为clustered 索引。

17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

18.尽可能的使用varchar/nvarchar 代替char/nchar , 因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

19.任何地方都不要使用select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。

20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限(只有主键索引)。

21.避免频繁创建和删除临时表，以减少系统表资源的消耗。

22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

23.在新建临时表时，如果一次性插入数据量很大，那么可以使用select into 代替create table,避免造成大量log ,以提高速度;如果数据量不大，为了缓和系统表的资源，应先create table,然后insert.

24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table ,然后drop table ,这样可以避免系统表的较长时间锁定。

25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1 万行，那么就应该考虑改写。

26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

27.与临时表一样，游标并不是不可使用。对小型数据集使用FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

28.在所有的存储过程和触发器的开始处设置SET NOCOUNT ON ,在结束时设置SET NOCOUNT OFF .无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC 消息。

29.尽量避免大事务操作，提高系统并发能力。sql 优化方法使用索引来更快地遍历表。缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。一般来说：

a.有大量重复值、且经常有范围查询( > ,< ,> =,< =)和order by、group by 发生的列，可考虑建立集群索引;

b.经常同时存取多列，且每列都含有重复值可考虑建立组合索引;

c.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引，维护索引集合就要做相应的更新工作。30.定期分析表和检查表。

分析表的语法：ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tb1_name[, tbl_name]...

以上语句用于分析和存储表的关键字分布，分析的结果将可以使得系统得到准确的统计信息，使得SQL能够生成正确的执行计划。如果用户感觉实际执行计划并不是预期的执行计划，执行一次分析表可能会解决问题。在分析期间，使用一个读取锁定对表进行锁定。这对于MyISAM，DBD和InnoDB表有作用。

例如分析一个数据表：analyze table table_name

检查表的语法：CHECK TABLE tb1_name[,tbl_name]...[option]...option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

检查表的作用是检查一个或多个表是否有错误，CHECK TABLE 对MyISAM 和InnoDB表有作用，对于MyISAM表，关键字统计数据被更新

CHECK TABLE 也可以检查视图是否有错误，比如在视图定义中被引用的表不存在。

31.定期优化表。

优化表的语法：OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tb1_name [,tbl_name]...

如果删除了表的一大部分，或者如果已经对含有可变长度行的表(含有VARCHAR、BLOB或TEXT列的表)进行更多更改，则应使用OPTIMIZE TABLE命令来进行表优化。这个命令可以将表中的空间碎片进行合并，并且可以消除由于删除或者更新造成的空间浪费，但OPTIMIZE TABLE 命令只对MyISAM、BDB 和InnoDB表起作用。

例如：optimize table table_name

注意：analyze、check、optimize执行期间将对表进行锁定，因此一定注意要在MySQL数据库不繁忙的时候执行相关的操作。

补充：

1、在海量查询时尽量少用格式转换。

2、ORDER BY 和GROPU BY:使用ORDER BY 和GROUP BY 短语，任何一种索引都有助于SELECT 的性能提高。

3、任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

4、IN、OR 子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

5、只要能满足你的需求，应尽可能使用更小的数据类型：例如使用MEDIUMINT 代替INT

6、尽量把所有的列设置为NOT NULL,如果你要保存NULL,手动去设置它，而不是把它设为默认值。

7、尽量少用VARCHAR、TEXT、BLOB 类型

8、如果你的数据只有你所知的少量的几个。最好使用ENUM 类型

9、正如graymice 所讲的那样，建立索引。

10、合理用运分表与分区表提高数据存放和提取速度。

数据表是在太小了，做一次全表扫描比做索引键的查找来得快多了。当表的记录总数小于10且记录长度比较短时通常这么做。

2)没有合适用于ON 或WHERE 分句的索引字段。

3)让索引字段和常量值比较，MySQL已经计算（基于索引树）到常量覆盖了数据表的很大部分，因此做全表扫描应该会来得更快。

4)通过其他字段使用了一个基数很小（很多记录匹配索引键值）的索引键。这种情况下，MySQL认为使用索引键需要大量查找，还不如全表扫描来得更快。

对于小表来说，全表扫描通常更合适。但是对大表来说，尝试使用以下技术来避免让优化程序错误地选择全表扫描：

1)执行ANALYZE TABLE tbl_name 更新要扫描的表的索引键分布。

2)使用FORCE INDEX 告诉MySQL，做全表扫描的话会比利用给定的索引更浪费资源。

SELECT * FROM t1, t2 FORCE INDEX (index_for_column)

WHERE t1.col_name=t2.col_name;

3)启动mysqld 时使用参数--max-seeks-for-key=1000 或者执行SET max_seeks_for_key=1000 来告诉优化程序，所有的索引都不会导致超过1000次的索引搜索

mysql数据库sql优化原则

这里的原则只是针对mysql数据库，其他的数据库某些是殊途同归，某些还是存在差异。我总结的也是mysql普遍的规则，对于某些特殊情况得特殊对待。在构造sql语句的时候养成良好的习惯

原则1、仅列出需要查询的字段，这对速度不会明显的影响，主要是考虑节省应用程序服务器的内存。

原来语句：select * from admin

优化为：select admin_id,admin_name,admin_password from admin

原则2、尽量避免在列上做运算，这样导致索引失效

原语句：select * from admin where year(admin_time)>2014

优化为：select * from admin where admin_time> '2014-01-01'

原则3、使用JOIN 时候，应该用小的结果驱动大的结果（left join 左边表结果尽量小如果有条件应该放到左边先处理，right join 同理反向），同事尽量把牵涉到多表联合的查询拆分多个query(多个连表查询效率低，容易到之后锁表和阻塞)

原来语句select * from admin left join log on admin.admin_id = log.admin_id where log.admin_id>10

优化为：select * from (select * from admin where admin_id>10) T1 left join log on T1.admin_id = log.admin_id 原则4、注意LIKE 模糊查询的使用，避免使用%% ,可以使用后面带% ，双%是不走索引的

原来语句：select * from admin where admin_name like '%de%'

优化为：select * from admin where admin_name >='de' and admin_nam <'df' (注意不是等效的这里试试提供优化的思路)原则5、使用批量插入节省交互（当如如果使用存储过程来处理批量的sql 各种逻辑是更好的选择）

原来语句：

insert into admin(admin_name,admin_password) values ('test1','pass1');

insert into admin(admin_name,admin_password) values ('test2','pass2');

insert into admin(admin_name,admin_password) values ('test3','pass3')

优化为：

insert into admin(admin_name,admin_password) values('test1','pass1'),('test2','pass2'),('test3','pass3')

原则6、limit 的基数比较大时使用between

原来语句：select * from admin order by admin_id limit 100000,10

优化为： select * from admin where admin_id between 100000 and 100010 order by admin_id

原则7、不要使用rand函数获取多条随机记录

原来语句：select * from admin order by rand() limit 20

优化为：select * from admin as t1 Join(select round(rand()*((select max(admin_id) from admin)-(select min(id) from admin))+(select min(id) from admin)) as id) as t2 where t1.id>=t2.id order by t1.id limit

原则8、避免使用NULL

否则将导致引擎放弃使用索引而进行全表扫描

原则9. 不要使用count(column) 使用count(*)

数据库对count(*) 计数操作做了一些特别的优化，

count(column) 是表示结果集中有多少个column字段不为空的记录

count(*) 是表示整个结果集有多少条记录

原则10、不要做无谓的排序操作，而应该使用索引完成排序

数据库优化包括两个方面，一方面是sql 程序优化，另一方面是数据库配置的优化。另外在mysl 可以通过以下语句来查看帮助sql进行优化

set @@profiling = 1;

select * from typecho_comments order mail limit 10,30;

show profiles;

show profile for query *