以下是使用MYSQL服务的一些经验，主要从以下几个方面考虑的MYSQL服务规划设计。
为了以后维护，升级备份的方便和数据的安全性，最好将MYSQL程序文件和数据分别安装在“不同的硬件”上。
1 复制缺省的mysql/var/mysql到 /data/app_1/目录下
1 多个服务启动：只需要修改脚本中的--port=参数。单个目录下的数据和服务脚本都是可以独立打包的。
尽量使用MYSQL DUMP而不是直接备份数据文件，以下是一个按weekday将数据轮循备份的脚本：备份的间隔和周期可以根据备份的需求确定
1 在crontab中'%'需要转义成'%'
1.非用数据库不可吗？
数据库的确可以简化很多应用的结构设计，但本身也是一个系统资源消耗比较大的应用。所以很多应用如果没有很高的实时统计需求的话，完全可以先记录到文件日志中，定期的导入到数据库中做后续统计分析。如果还是需要记录2维表结构，结构足够简单的话可以使用DBM结构。即使需要使用数据库的，应用如果没有太复杂的数据完整性需求的化，完全可以不使用那些支持外键的商业数据库。
2.数据库服务的主要瓶颈：单个服务的连接数对于一个应用来说，如果数据库表结构的设计能够按照数据库原理的范式来设计的话，并且已经使用了最新版本的MYSQL，并且按照比较优化的方式运行了，那么最后的主要瓶颈一般在于单个服务的连接数，即使一个数据库可以支持并发500个连接，最好也不要把应用用到这个地步，因为并发连接数过多数据库服务本身用于调度的线程的开销也会非常大了。所以如果应用允许的话：让一台机器多跑几个MYSQL服务分担。将服务均衡的规划到多个MYSQL服务端口上：比如app_1 ==> 3301 app_2 ==> 3302…app_9 ==> 3309。一个1G内存的机器跑上10个MYSQL是很正常的。让10个MYSQLD承担1000个并发连接效率要比让2个MYSQLD承担1000个效率高的多。当然，这样也会带来一些应用编程上的复杂度；
3.使用单独的数据库服务器（不要和前台WEB服务抢内存），MYSQL拥有更多的内存就可能能有效的进行结果集的缓存；
4.应用尽量使用PCONNECT和polling机制，用于节省MYSQL服务建立连接的开销；
5.表的横向拆分：让最常被访问的10%的数据放在一个小表里，90%的历史数据放在一个归档表里，数据中间通过定期“搬家”和定期删除无效数据来节省。这样对于应用来说总是在10%数据中进行选择，比较有利于数据的缓存，不要指望MYSQL中对单表记录数在10万级以上还有比较高的效率。
6.表的纵向拆分（过渡范化）：将所有的定长字段（char, int等）放在一个表里，所有的变长字段（varchar,text,blob等）放在另外一个表里，2个表之间通过主键关联，这样，定长字段表可以得到很大的优化（甚至可以使用HEAP表类型，数据完全在内存中存取），这里也说明另外一个原则，对于我们来说，尽量使用定长字段可以通过空间的损失换取访问效率的提高。MYSQL之所以支持多种表类型，实际上是针对不同应用提供了不同的优化方式；
7.仔细的检查应用的索引设计，甚至在服务启动中加入 --log-slow-queries[=file]用于跟踪分析应用瓶颈。