mysql优化

最常见的瓶颈是：

• 磁盘寻道。磁盘花时间找到一个数据，用在1999年的现代磁盘其平均时间通常小于10ms，因此理论上我们能大约一秒寻道 1000 次。这个时间用新磁盘提高很慢并且很难对一个表优化。优化它的方法是将数据散布在多个磁盘上。
• 当磁盘在我们需要读数据的正确位置时，磁盘读/写。用1999年的现代，一个磁盘传输类似10-20Mb/s。这必寻道更容易优化，因为你能从多个磁盘并行地读。
• CPU周期。当我们读数据进内存时，(或如果它已经在那里)我们需要处理它以达到我们的结果。当我们有相对内存较小的表时，这是最常见的限制因素，但是用小表速度通常不是问题。
• 内存带宽。当CPU需要超出适合cpu缓存的数据时，缓存带宽就成为内存的一个瓶颈。这是对大多数系统的一个不常见的瓶颈但是你应该知道它。

 

编译和链接怎样影响MySQL的速度

1)       如果你动态地链接 ( 没有 -static ) ，结果慢了 13% 。

2)       如果你使用 TCP/IP 而非 Unix 套接字，结果慢 7.5% 。

 

磁盘问题

1)      使用镜像

2)      使用符号链接的表或数据库

 

调节服务器参数

       比较有效且常用的手段

 

表级操作的锁定

       要保证线程安全的操作

 

使用索引

       具体参考另文：MySQL查找的方式与索引的效率.doc

 

查询性能的计算，改进

    在大多数情况下，你能通过计算磁盘寻道估计性能。对小的表，你通常能在 1次磁盘寻道中找到行(因为这个索引可能被缓冲)。对更大的表，你能估计它(使用 B++ 树索引)，你将需要： log(row_count)/log(index_block_length/3*2/(index_length + data_pointer_length))+1次寻道找到行。

在 MySQL中，索引块通常是 1024个字节且数据指针通常是4个字节，这对一个有一个索引长度为3(中等整数)的 500,000 行的表给你： log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 次寻道。

象上面的索引将要求大约 500,000 * 7 * 3/2 = 5.2M，(假设索引缓冲区被充满到2/3(它是典型的))，你将可能在内存中有索引的大部分并且你将可能仅需要1-2调用从OS读数据来找出行。

然而对于写，你将需要 4 次寻道请求(如上)来找到在哪儿存放新索引并且通常需2次寻道更新这个索引并且写入行。

 

insert, update, delete的性能估计与改进

 

总的建议

使用持久的连接数据库以避免连接开销。

总是使用索引。