@akalanala 人家有心就是好的。不要浇灭人家的热情

数据库几百并发，你做的项目有点大啊，有多少台服务器要连你的数据库啊？

openresty 不就是擅长高并发的嘛
不过据我粗浅的了解,还是要注意很多方面才能扛得住

几百并发可以玩玩memcache顶顶吧

数据库几百并发不算少了吧，网站的话，都是日均百万pv级别了。

之前在dbanote还是nosql看到过一篇讲新浪架构的，那个对你应该有点帮助。

软件上能精简的都精简，甚至硬件都特殊定制。
比如apache，不用的部分就连代码都删掉。比如google连服务器都自己造.

1.把需要执行10秒的sql优化成0.x秒
2.花钱买硬件

@kennedy32
几百并发的优化用独立数据库服务器很扯淡，堪称治标不治本。

这种情况把程序操作数据库的优化部分掌握好基础并实践就足够了。

上面说的都有道理，其实最基础的还是把程序优化好，再做其他的，要不然都是扯淡。

1. 尽量别依赖数据库来实现数据的关联关系。
知乎内部的 MySQL 使用准则中，就禁止使用 JOIN、GROUP BY、子查询和外键。
说实话，这等于使用非关系型数据库了。

2. 查询主要靠缓存和索引。
但千万别乱加缓存和索引，它们和表的结构、业务逻辑、使用频率之间有且只有一个最优解。
你只能靠经验和测试来寻找，而且越到后期，这些就越难改动。

做到这 2 点还有瓶颈的话，基本也是价值不菲司了，也不会缺有经验的 DBA 了。
这时的瓶颈主要在写了，就通过分离读写、分库、使用 SSD 的方式来满足吧。这部分我也不熟。

搞着几百并发的事, 操着几千万并发的心... 楼主还是先歇歇吧.

@Livid 确实需要这样一个机会

@likuku 只用了memcache

高性能MySQL ＋ 靠谱的生产环境项目

可以考虑把数据库分离出来，aws或者aliyun都有提供单独的数据库服务器

都是靠横向和纵向扩展的

业务系统的关系数据库查询和插入都很复杂的，就算你能把操作平均到10毫秒，一秒也就能处理100个，但实际情况是远远达不到。 但你可能通过扩展多个工作进程达到n倍的性能改进。

但最终，数据库又是瓶颈，你只好再对数据库做扩展（但对关系数据库做扩展都比较麻烦）， 或使用内存数据库。 很多人使用mongdb, 无非就是他标称的快和所谓的扩展能力。

「现在连mysql 几百并发都搞不定啊」

烂的SQL语句可以让机器表现变慢1万倍。

充分利用缓存了没？用好缓存能解决绝大部分「性能问题」。

web静态缓存(varnish/squid)，对象内存缓存(memcached)，db 查询缓存，等等。

大数据需要的也是大机器，而且是不止一台大机器。当你手上有一堆大机器时，需要做的就是设计一个能够应对灾难状况的架构，及尽可能在流量高峰能够吃透这些机器的性能。到一家大公司参与一个有规模的项目，是学习这些技术最快的方式。