I/O基准测试只是一种观察的方式，MySQL在SAN上具体性能表现如何?在许多情况下，MySQL运行得还可以，可以避免很多SAN可能导致性能下降的情况。仔细地做好逻辑和物理设计，包括索引和适当的服务器硬件(尽量配置更多的内存!)可避免很多的随机I/O操作，或者可以转化为顺序的I/O。然而，应该知道的是，通过段时间的运行，这种系统可以达到一个微妙的平衡一引入 一 个新的查询，Schema的变化或频繁的操作，都很容易扰乱这种平衡。

        例如，一个SAN用户，我们知道他对每天的性能表现非常满意，直到有天他想清理一张变得非常大的旧表中的大量数据行。这会导致一个长时间运行的DELETE语句，每秒只能删几百行，因为删除每行所需的随机I/O，SAN无法有效快速地执行。有没有办法来加快操作，它只是要花费很长的时间才能完成。另个让他大吃一 惊的事是，当对一个大表执行ALTER类似的操作时明显速度减慢。

        这些都是些典型的例子,哪些工作放在SAN上不合适:执行大量的随机I/0的单线程任务。在当前版本的MySQL中，复制是另一个 单线程任务。因此，备库的数据存储在saN上，可能更容易落后于主库。批处理作业也可能运行得更慢。在非高峰时段或周末执行一个一次性的延迟敏感的操作是 可以的，但是服务器的很多部分依然需要很好的性能，例如拷贝、二进制日志，以及InnoDB的事务日志上总是需要很好的小随机I/O性能。