一、我们可以且应该优化什么？

　　硬件

　　操作系统/软件库

　　SQL服务器(设置和查询)

　　应用编程接口(API)

　　应用程序

　　二、优化硬件

　　如果你需要庞大的数据库表(>2G)，你应该考虑使用64位的硬件结构，像Alpha、Sparc或即将推出的IA64。因为MySQL内部使用大量64位的整数，64位的CPU将提供更好的性能。

　　对大数据库，优化的次序一般是RAM、快速硬盘、CPU能力。

　　更多的内存通过将最常用的键码页面存放在内存中可以加速键码的更新。

　　如果不使用事务安全(transaction-safe)的表或有大表并且想避免长文件检查，一台UPS就能够在电源故障时让系统安全关闭。

　　对于数据库存放在一个专用服务器的系统，应该考虑1G的以太网。延迟与吞吐量同样重要。

　　三、优化磁盘

　　为系统、程序和临时文件配备一个专用磁盘，如果确是进行很多修改工作，将更新日志和事务日志放在专用磁盘上。

　　低寻道时间对数据库磁盘非常重要。对与大表，你可以估计你将需要log(行数)/log(索引块长度/3*2/(键码长度 + 数据指针长度))+1次寻到才能找到一行。对于有500000行的表，索引Mediun int类型的列，需要log(500000) / log(1024/3*2/(3 + 2))+1=4次寻道。上述索引需要500000*7*3/2=5.2M的空间。实际上，大多数块将被缓存，所以大概只需要1-2次寻道。

　　然而对于写入（如上），你将需要4次寻道请求来找到在哪里存放新键码，而且一般要2次寻道来更新索引并写入一行。

　　对于非常大的数据库，你的应用将受到磁盘寻道速度的限制，随着数据量的增加呈N log N数据级递增。

　　将数据库和表分在不同的磁盘上。在MySQL中，你可以为此而使用符号链接。

　　条列磁盘(RAID 0)将提高读和写的吞吐量。

　　带镜像的条列(RAID 0+1)将更安全并提高读取的吞吐量。写入的吞吐量将有所降低。

　　不要对临时文件或可以很容易地重建的数据所在的磁盘使用镜像或RAID(除了RAID 0)。

　　在Linux上，在引导时对磁盘使用命令hdparm -m16 -d1以启用同时读写多个扇区和DMA功能。这可以将响应时间提高5~50%。

　　在Linux上，用async (默认)和noatime挂载磁盘(mount)。

　　对于某些特定应用，可以对某些特定表使用内存磁盘，但通常不需要。