新手初来发帖，请问 mysql 使用 SSD 阵列后性能会改善多少？

有一个较高并发查询的mysql记录，就一张表数据格式也只有1种，但是有100万条数据，没有长文本，没有建立索引，用户大约有10万左右，在高峰时段这些用户几乎都在同时查询，并且是实时查询。。这可能会很恐怖之类的，mysql可能会各种死的很惨，因为资金和技术所限，现有的解决方案就是单独架设一台采用8核CPU和32G内存、双512G SSD阵列组成的mysql数据库服务器与主服务器连接，不知道行不行。如果不行是不是需要上Memcache呢？

MySQL

阵列

查询

22 条回复 • 2015-01-25 19:33:06 +08:00

msg7086

2014-10-07 21:23:05 +08:00 via iPhone

建立索引。100000qps上啥ssd都没用啊。

Zhang

2014-10-07 21:44:58 +08:00

http://dev.mysql.com/doc/refman/5.5/en/optimization-indexes.html

Zhang

2014-10-07 21:45:13 +08:00

清醒白醒地写着的。

aruisi

2014-10-07 22:28:38 +08:00

@Zhang 这里说了些建立索引改善IO和使用缓存这些。具体实施起来怎么做呢？

cloudzhou

2014-10-07 22:33:06 +08:00

这个数据量对 mysql 还是很轻松的，关键是索引和缓存使用得当，缓存分几个级别。

ryd994

2014-10-07 22:42:54 +08:00

@aruisi
建立索引是基本吧…………
另外高并发建议innodb，最近的测试显示innodb读写性能都远超myisam
memcache能上就上吧，使用得当的话效果不是一般两般的
其实最好还是优化需求，减少不必要的查询

est

2014-10-07 22:47:37 +08:00

没找到1亿投资之前不要怀疑mysql 性能问题。多怀疑自己操办mysql 姿势问题。

sivacohan

2014-10-08 00:01:22 +08:00 via Android

不是应该用pcie吗

FatGhosta

2014-10-08 00:02:02 +08:00

（楼上的同志们能就事论事么。。。）
我也是听同事说的啊，我们同事有个重要的数据库，量也比较大。然后前阵子尝试用上了ssd。同事说速度基本没有提高。。。

fatpa

2014-10-08 00:08:15 +08:00

读写速度快

66450146

2014-10-08 00:08:39 +08:00

你的第一反应居然不是建立索引而是用 SSD 和 memcached？？？？？？？？？？？

msg7086

2014-10-08 07:21:15 +08:00

@FatGhosta SSD对于提高qps效果很好，前提是你的查询是随机查询而非线性读。

线性读最典型的就是没法利用索引的情况下，得把整个表都读出来做整表扫描。

优化得好的话SSD能大幅提升处理速度。

手头有个discuz论坛，忙时大约200qps，以前用HDD基本会跟不上请求节奏，换上SSD以后速度快很多。做Replication的机器本来也是HDD，也是跟不上请求节奏，晚上高峰的查询都要到凌晨人都睡觉以后才能逐渐处理完。换上SSD以后超过1500qps，整整一晚上的请求堆在一起跑也只要几分钟就能跑完了。

0zero0

2014-10-08 08:41:35 +08:00

SSD的寿命和稳定性在这种情况下堪忧

xzl

2014-10-08 08:47:18 +08:00

@0zero0 说的是提升性能，寿命和稳定性可以依托Raid和Replication。

aruisi

2014-10-08 09:59:29 +08:00

@est
@ryd994
@est
@sivacohan
@FatGhosta
@fatpa
@66450146
@66450146
@msg7086
@0zero0
@xzl
感谢大家的友情回复。我详细说下这个系统，是客户提出的要求，他是个微型运营商，要个用于城域网的递归DNS，用bind-dlz搭建，同时需要过滤掉大量不法网站（主要是反动色情之类吧）由客户提供100万+的需要过滤的域名加载到dlz的mysql数据库中，如果不用数据库，bind加载zone记录需要100G内存，光加载时间就需要3个小时，城域网用户大约是10万+，查了一些资料10万级用户对DNS的qps需求大约在1000-1500qps，高峰时在2000-3000qps。当bind开启dlz后性能会下降30倍左右，这与买票网站或者论坛不同，论坛不是所有用户都在不停的查询，而DNS却是所有用户只要一上网就开始在后台不停的查询查询。而如果上高速缓存，因为这些要过滤的网站没有啥规则或者区分哪些是热数据，缓存命中率也是问题，缓存上多少呢，就怕mysql在高峰时出现崩溃，这样所有用户都上不了网了。

finfou

2014-10-08 14:30:07 +08:00

一些思路，DNS查询的话明显主要是读操作，少量写操作。这种情况LDAP应该比较合适，是针对读优化的。
另外，自己写一个域名过滤应该也可以满足需求吧，100w记录，建一个字典树，查询时间是url长度，内存是100w*平均长度，大概1g内存可以放下了

VYSE

2014-10-08 14:43:16 +08:00

@aruisi 100万个需要过滤的域名不经常删除的话，还这么多内存的话，innodb+memcache绝配： http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html
当然你也可以压榨硬件极限下MYSQL配置试试： https://tools.percona.com/wizard
建议多压力测试和注意监控memory overcommitted crash

ryd994

2014-10-08 23:33:20 +08:00 via Android

@aruisi 再加一级DNS当缓存
对屏蔽的域名返回一个无效IP，这样下降DNS就会缓存这个结果。DNS污染而已

ryd994

2014-10-08 23:39:03 +08:00 via Android

@aruisi 缓存命中多少是多少，不会亏。
至于可靠性可以试试做一个中间层容错，如果数据库崩溃就不过滤。屏蔽域名的话，肯定有些域名尝试的人多，比如Google，有些域名没人知道就少，这个时候索引的作用就出来了，因为不需要遍历数据库而是二分就行。
意见不变：首先建立索引试试，不行的话再加一级bind，不行的话再加缓存

ryd994

2014-10-09 03:20:06 +08:00

100w，建立索引就是最多20次搜索，不建立索引就是100w次，差别多大，你自己看。
而且不建立索引的话ssd的优势完全看不出，因为反正是要遍历的。

aruisi

2014-10-09 11:28:36 +08:00

@finfou
@VYSE
@ryd994 非常感谢各位，目前技术十分有限，做不了这些高大上的东西，正在到处找外包的看能做不。

alsotang

2015-01-25 19:33:06 +08:00

@ryd994 对的，不建立索引的话，会是顺序扫硬盘，ssd 的优势就不明显了。