从架构和性价比考虑，ssd一般用于线上IO密集型，sas用于普通线上业务而stat仅用于线下测试。 对于四块盘做raid的性能比较raid0>raid10>raid5>raid1，但是raid0并没有数据恢复的功能，索引一般会选择raid10，盘多会选择raid5或raid6，进而架构为主库raid10，从库raid0

软件优化

1. 操作系统首选64位，32位会有4G进程限制，当然CPU也得对应为64位
2. 操作系统参数优化，这个值得研究（待续）
3. 软件通过编译安装，优化例如：静态库，静态编译，禁止debug等

参数优化

参数问题优化幅度很小，可以提一些主要的参考项

innodb_buffer_pool_size = 80%内存 不过建议30%~50%
sort_buffer_size = 2M 这个不用给特别大，因为是一个线程的buffer，同样的参数还有joinbuffer，readbuffer
open_files_limit = 65536 最大文件打开数，需要操作系统同样调大
query_cache_size = 64M  
query_cache_limit = 4M  查询缓存的限制
query_cache_min_res_unit = 2k 资源大小
tmp_table_size = 256M 临时表大小
long_query_time = 2  慢查询时间，单位为s
log-slow-queries = 慢查询日志存放目录，超过上述时间的就放入到这个日志中
relay-log
relay-log- info-file        级联同步需要开启
expire_logs_days = 7     bin-log自动清除时间
key_buffer_size =32M    索引缓存，如果是MyISAM引擎可能变大为2048M
skip-name-resolve       会有用户权限的一些问题，其他主机在连接的 时候会检查反向代理
innodb_data_file_path = ibdata1:1024M:ibdata2:1024M:autoextend  这个可以设置多个
table_cache = 512 为所有线程打开表的数量，增加该值能增加mysqld要求的文件描述符数量，避免频繁打开数据表的开销
wait_timeout 服务器在关闭它之前在上一个连接等待行动的秒数
interactive_timeout 默认为28800，8小时
max_allowed_packet = 16M 服务器与客户端之间最大能发送的可能信息包，可以提高备份的效率

一般情况下的参数会调整为一个大概的值，然后进过测试或者监控工具调试，根据业务进行细化 例如show global status\G来查看这些参数的使用情况，我用过比较好用的工具是mysqlreport 也提供了一个测试脚本的下载http://www.day32.com/MySQL/tuning-primer.sh

SQL语句优化

1. 索引优化 抓取慢sql，可以通过一些工具来进行分析，例如mysqlsla，当然还有一些别的mysqldumpslow，myprofi，mysql-explain-slow-log，mysqllogfile等 每天晚上0点定时分析慢查询发到核心开发，DBA，高级运维，CTO的邮箱，由DBA分析，是建索引，还是拆分，然后由核心开发修改，高级运维旁听，并使CTO做到知情 百度因为大量的业务也产生了SQL的白名单机制。
2. 大的复杂的SQL语句拆分 大的复杂的SQL语句拆分为子查询，join联表查询，如果上几千万的数据，这些优化可能就没有太大的效果，可能就要拆表拆库来进行优化

3. 数据库是存储数据的地方 把计算放到应用的处理由前端程序和应用来解决，另外搜索不要用数据库，产生类似like %a%的语句

   架构优化

4. 业务拆分，搜索功能放到程序，某些业务使用nosql，例如memcachedb，redis存储一些中间结果，好友关系

5. 数据库前端cache，例如：用户登录，商品查询
6. 动态数据静态化，例如一些新闻，博客等数据，页面片段静态化
7. 数据库集群读写分离，一主多从，通过程序或者dbproxy进行集群读写分离

流程制度优化

有很多的问题，都是因为内部问题或者是为了给内部提供方便导致的问题，要对权限有一个很好的认识，防患于未然，运维的价值体现在对出现的问题及时的解决，但是更多的还是把这些问题防患于未然。