您现在的位置是:芭奇站群管理系统 > 优化技巧 > -> mysql优化应该注意的几点

mysql优化应该注意的几点

时间:2010-05-19 22:50

  如果大家有异议,可以在后面补充。我会随时更新的。

  现在大概列出如下:(望各位补充)

  1.数据库的设计

  尽量把数据库设计的更小的占磁盘空间.

  1).尽可能使用更小的整数类型.(mediumint就比int更合适).

  2).尽可能的定义字段为notnull,除非这个字段需要null.(这个规则只适合字段为key的情形)

  3).如果没有用到变长字段的话比如varchar,那就采用固定大小的纪录格式比如char.(char总是比varchr快)

  4).表的主索引应该尽可能的短.这样的话每条纪录都有名字标志且更高效.

  5).只创建确实需要的索引。索引有利于检索记录,但是不利于快速保存记录。如果总是要在表的组合字段上做搜索,那么就在这些字段上创建索引。索引的第一部分必须是最常使用的字段.如果总是需要用到很多字段,首先就应该多复制这些字段,使索引更好的压缩。

  (这条只适合myisam引擎的表,对于innodb则在保存记录的时候关系不大,因为innodb是以事务为基础的,如果想快速保存记录的话,特别是大批量的导入记录的时候)

  6).所有数据都得在保存到数据库前进行处理。

  7).所有字段都得有默认值。

  8).在某些情况下,把一个频繁扫描的表分成两个速度会快好多。在对动态格式表扫描以取得相关记录时,它可能使用更小的静态格式表的情况下更是如此。

  (具体的表现为:myisam表的merge类型,以及myisam和innodb通用的分区,详情见手册)

  9).不会用到外键约束的地方尽量不要使用外键。

  2.系统的用途

  1).及时的关闭对mysql的连接。

  2).explain复杂的sql语句。(这样能确定你的select语句怎么优化最佳)

  3).如果两个关联表要做比较话,做比较的字段必须类型和长度都一致.(在数据庞大的时候建立index)

  4).limit语句尽量要跟orderby或者distinct.这样可以避免做一次fulltablescan.

  5).如果想要清空表的所有纪录,建议用truncatetabletablename而不是deletefromtablename.

  不过有一个问题,truncate不会在事务处理中回滚。因为她要调用createtable语句。

  (truncatetable语句先删除表然后再重建,这个是属于文件级别的,所以自然快n多)

  实测例子:song2为innodb表。mysql>selectcount(1)fromsong2;+----------+count(1)+----------+  500000+----------+1rowinset(0.91sec)mysql>deletefromsong2;queryok,500000rowsaffected(15.70sec)mysql>truncatetablesong2;queryok,502238rowsaffected(0.17sec)

  6).能使用storeprocedure或者userfunction的时候.(routine总是减少了服务器端的开销)

  7).在一条insert语句中采用多重纪录插入格式.而且使用loaddatainfile来导入大量数据,这比单纯的indert快好多.(在mysql中具体表现为:insertintotableqvalues(),(),...();)

  (还有就是在myisam表中插入大量记录的时候先禁用到keys后面再建立keys,具体表现语句: altertabletable1disablekeys;altertabletable1enablekeys;而对于innnodb表在插入前先setautocommit=0;完了后:setautocommit=1;这样效率比较高。)

  8).经常optimizetable来整理碎片.

  9).还有就是date类型的数据如果频繁要做比较的话尽量保存在unsignedint类型比较快。

  3.系统的瓶颈

  1).磁盘搜索.

  并行搜索,把数据分开存放到多个磁盘中,这样能加快搜索时间.

  2).磁盘读写(io)

  可以从多个媒介中并行的读取数据。

  3).cpu周期

  数据存放在主内存中.这样就得增加cpu的个数来处理这些数据。

  4).内存带宽

  当cpu要将更多的数据存放到cpu的缓存中来的话,内存的带宽就成了瓶颈.

  ==== anotherarticlemoreabouttuningdetails:abcdinformit.com/articles/article.aspx?p=29406&seqnum=1