1、首先要搞明白什么叫执行计划？ 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生欀如一条SQL语句如果用来从一个10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。 可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要： (1)    SQL语句是否清晰地告诉查询优化器它想干什么？ (2)    查询优化器得到的数据库统计信息是否是最新的、正确的？ 2、统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。 select * from dual select * From dual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。 所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！ 3、不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。 一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。 另外，执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。而复杂的SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞在内存里。可想而知，数据库的效率会何等低下。 4、使用“临时表”暂存中间结果 简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。 5、 OLTP系统SQL语句必须采用绑定变量  select * from orderheader where changetime > ’2010-10-20 00:00:01′ select * from orderheader where changetime > ’2010-09-22 00:00:01′ 以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。 如果采用绑定变量 select * from orderheader where changetime > [...]

1.数据库的对象： 1）优化表的类型： 2) 数据库表设计时候更小的占磁盘空间尽可能使用更小的整数类型.(mediumint就比int更合适) 3) 所有字段都得有默认值 4) 选择合适表类型（InnoDB或者myisam） 2,优化sql语句： 1）通过show status了解各种sql的执行频率 show status like ‘Com_%’ 了解 Com_select,Com_insert 的执行次数 2) 通过Explain分析低效的sql语句 3) 建立合适的索引 4) 通过show status like ‘Handler_%’查看索引的使用情况 handler_read_key表明索引效率的很高 Handler_read_rnd_key的值很高，表明查询运行效率很低 5) 定期分析表和检查表 analyze table test_table和check table test_table 然后查看Msg_text字段的值是否是ok 6）定期优化表 optimize table test_table 如果对表的字段varchar blob，text等进行了很多更改， 则撒花用 7) 优化 order by orgroup by等 3，锁的问题 1) MyISAM为表级锁 由于MyISAM写进程优先获得锁，使得读锁请求靠后等待队列 如果在大量更新操作的情况下，使得很难获得读锁。从而造成阻塞。 [...]