mysql的一些处理方法

beluckly

遇到数据交互大时，一般会采用下面两种方式对数据库进行分割
一种是垂直分割，对表进行切割
像Mixi.jp就是根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了
表进行截断操作：
– FLUSH TABLES; TRUNCATE TABLE ad_stats0;
这样的操作对Master数据库是成功的，但对Slave会失败，正确的截断子表方法是：
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2);
– TRUNCATE TABLE ad_stats0;
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2);

还有一种就是水平分割，按照表的内容将不同的表划分到不同的数据库中
FB（
FeedBurner
）的运维总监Joe Kottke给了四点建议：
1、 监控网站数据库负载。
2、 “explain”所有的SQL语句。
3、 缓存所有能缓存的东西。
4、 归档好代码。
BTW：memcached一直是众多网站缓存数据的利器，像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库
图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录
参考资料：
http://www.example.net.cn/archives/2006/06/feedburneruoumy.html
http://www.example.net.cn/archives/2006/06/mixijpeoaoeiiae.html


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/14986/showart_1073531.html