I/O基准测试只是一种观察的方式,MySQL在SAN上具体性能表现如何?在许多情况下,MySQL运行得还可以,可以避免很多SAN可能导致性能下降的情况。仔细地做好逻辑和物理设计,包括索引和适当的服务器硬件(尽量配置更多的内存!)可避免很多的随机I/O操作,或者可以转化为顺序的I/O。然而,应该知道的是,通过段时间的运行,这种系统可以达到一个微妙的平衡一引入 一 个新的查询,Schema的变化或频繁的操作,都很容易扰乱这种平衡。
例如,一个SAN用户,我们知道他对每天的性能表现非常满意,直到有天他想清理一张变得非常大的旧表中的大量数据行。这会导致一个长时间运行的DELETE语句,每秒只能删几百行,因为删除每行所需的随机I/O,SAN无法有效快速地执行。有没有办法来加快操作,它只是要花费很长的时间才能完成。另个让他大吃一 惊的事是,当对一个大表执行ALTER类似的操作时明显速度减慢。
这些都是些典型的例子,哪些工作放在SAN上不合适:执行大量的随机I/0的单线程任务。在当前版本的MySQL中,复制是另一个 单线程任务。因此,备库的数据存储在saN上,可能更容易落后于主库。批处理作业也可能运行得更慢。在非高峰时段或周末执行一个一次性的延迟敏感的操作是 可以的,但是