是说的横向拆分吗

对恩，横向拆分的时候，程序或者 DB 设计应该注意些什么？比如锁，事务？都神么样的方案，好像有 mysql ndb

事务肯定不能用 mysql 自带的了，哪个事务只支持单个数据库内部事务。 拆分要重新设计表结构，以及业务流程，设置重新设计数据库，避免跨库事务，如果非要跨的话，需要自己写代码来保证数据的一致性。

关系型数据库在水平扩展上都非常痛苦，不是一句话两句话能说清楚的。

方案一是 MySQL 的复制，一个 Master 数据库，多个 Salve，然后利用 MySQL 的异步复制能力实现读写分离，这个方案目前应用比较广泛，但是不怎么好玩。

方案二是 MySQL 的 Sharding 策略，很不巧的是 MySQL 在设计之初就没有考虑过很好的支持自动 Sharding。特别是构建一个自动基于应用的数据分区和负载均衡，以及单点故障处理等等，用 MySQL 实现 Sharding 的话，Sharding 逻辑在你的应用内手动实现的并维护，要手动 Sharding 非常不容易，而且规划好避免每个单机 MySQL 实例的负载过重，以及不同 Sharding 中的数据迁移相当费事，可谓困难重重。这些在后面发展起来的 NoSQL 就处理的很好，比如 MongoDB，甚至自动 Sharding 成了 MongoDB 的核心功能。

#4 楼 @lgn21st 做水平扩展没有一些现成的东西吗，大家都手动 sharding。

那确实单点问题，数据分片都是个大问题。那个 mysql ndb 有实际使用吗？好像淘宝也有开源的类库？

另外 MySQL 的复制，如果数据量大了还是得做 sharding 吧。。。sharding 最后逃不掉啊感觉

#5 楼 @ihlayy 你说的这些都是关系数据库长久的痛点，可能有一些工具和库，但是好用的，信得过的有没有我不知道，我自己的方案是绕行到 MongoDB 上去。

#6 楼 @lgn21st

我们老总对 mongodb 还是有所顾忌的。。喜欢 redis+mysql 的架构方式。。

nosql 这块到时候还是要研究下唉，品种太多了

我们现在 mysql 分主从，读写分离。缓存使用 redis，自己写了一个将 mysql 导 redis 的小系统。

没实际操作过大数据量，想问下，每天大概有 300W 的访问量，会有大量的图片上传，会有交易。应该考虑怎样的架构？

#8 楼 @xiaogui

还是有经验的唉。。我之前都没做过数据量比较大的，这次悲催了，多指导唉

#9 楼 @ihlayy 不知道你项目的详细情况，先说几句： 1、把图片相关的操作与其他业务分离，图片相关的上传比较消耗磁盘 io 2、mysql 作个主从读写分离，将那种＂不是更新后马上需要读取的读操作＂放在从库操作。