个人的观点，这种大表的优化，不一定上来就要分库分表，因为表一旦被拆分，开发、运维的复杂度会直线上升，而大多数公司是欠缺这种能力的。所以MySQL中几百万甚至小几千万的表，先考虑做单表的优化。
单表优化可以从这几个角度出发：
表分区：MySQL在5.1之后才有的，可以看做是水平拆分，分区表需要在建表的需要加上分区参数，用户需要在建表的时候加上分区参数；分区表底层由多个物理子表组成，但是对于代码来说，分区表是透明的；SQL中的条件中最好能带上分区条件的列，这样可以定位到少量的分区上，否则就会扫描全部分区。
读写分离：最常用的优化手段，写主库读从库；
增加缓存：主要的思想就是减少对数据库的访问，缓存可以在整个架构中的很多地方，比如：数据库本身有就缓存，客户端缓存，数据库访问层对SQL语句的缓存，应用程序内的缓存，第三方缓存（如Redis等）；
字段设计：单表不要有太多字段；VARCHAR的长度尽量只分配真正需要的空间；尽量使用TIMESTAMP而非DATETIME；避免使用NULL，可以通过设置默认值解决。
索引优化：索引不是越多越好，针对性地建立索引，索引会加速查询，但是对新增、修改、删除会造成一定的影响；值域很少的字段不适合建索引；尽量不用UNIQUE，不要设置外键，由程序保证；
SQL优化：尽量使用索引，也要保证不要因为错误的写法导致索引失效；比如：避免前导模糊查询，避免隐式转换，避免等号左边做函数运算，in中的元素不宜过多等等；
NoSQL：有一些场景，可以抛弃MySQL等关系型数据库，拥抱NoSQL；比如：统计类、日志类、弱结构化的数据；事务要求低的场景。
数据量进一步增大的时候，就不得不考虑表拆分的问题了：
垂直拆分：垂直拆分的意思就是把一个字段较多的表，拆分成多个字段较少的表；上文中也说过单表的字段不宜过多，如果初期的表结构设计的就很好，就不会有垂直拆分的问题了；一般来说，MySQL单表的字段最好不要超过二三十个。
水平拆分：就是我们常说的分库分表了；分表，解决了单表数据过大的问题，但是毕竟还在同一台数据库服务器上，所以IO、CPU、网络方面的压力，并不会得到彻底的缓解，这个可以通过分库来解决。水平拆分优点很明显，可以利用多台数据库服务器的资源，提高了系统的负载能力；缺点是逻辑会变得复杂，跨节点的数据关联性能差，维护难度大（特别是扩容的时候）。
评论0
加载中...
MySQL数据库是在国内各大公司最常用的数据库之一，MySQL是一种开源的关系型数据库。而对于数据库的优化我认为可以从以下几个方面进行：
1.数据库配置优化在安装MySQL数据库时，可以对于数据库进行优化，增加数据库的连接数，增加访问量，访问量的增加可以提高查询速度。增加缓存等优化数据库，在查询时，可以直接在缓存中查询数据；
2.表结构优化在创建表结构时，一张数据表中不要创建过多的字段，如果一个功能的数据表结构中字段较多，可以尝试将字段分离出来，分别建成两个或多个表。而且对于字段的长度够用即可，不要设置的过长；
3.索引优化可以在数据库中，对于经常使用的表建立索引，索引可以增加查询的速度。但是索引不是越多越好，过多的索引反而会减慢查询的速度。针对性地建立索引会加速查询，但是对新增、修改、删除会造成一定的影响；
4.SQL查询优化在SQL查询时可以通过优化SQL的查询进行优化，通过增加查询的条件优化SQL，在多表关联的查询中，尽量不要使用自关联和全关联的方式进行，而是使用左右关联的方式进行查询。查询语句将字段写出来，不要使用select * from t(表名)的方式进行。
评论0
加载中...
一、Mysql分库分表方案
1.为什么要分表：当一张表的数据达到几千万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
mysql中有一种机制是表锁定和行锁定，是为了保证数据的完整性。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。
2. mysql proxy：amoeba做mysql集群,利用amoeba。
从上层的java程序来讲，不需要知道主服务器和从服务器的来源，即主从数据库服务器对于上层来讲是透明的。可以通过amoeba来配置。
3.大数据量并且访问频繁的表，将其分为若干个表比如对于某网站平台的数据库表-公司表，数据量很大，这种能预估出来的大数据量表，我们就事先分出个N个表，这个N是多少，根据实际情况而定。
某网站现在的数据量至多是5000万条，可以设计每张表容纳的数据量是500万条，也就是拆分成10张表，
那么如何判断某张表的数据是否容量已满呢？可以在程序段对于要新增数据的表，在插入前先做统计表记录数量的操作，当<500万条数据，就直接插入，当已经到达阀值，可以在程序段新创建数据库表（或者已经事先创建好），再执行插入操作。
4. 利用merge存储引擎来实现分表如果要把已有的大数据量表分开比较痛苦，最痛苦的事就是改代码，因为程序里面的sql语句已经写好了。用merge存储引擎来实现分表, 这种方法比较适合.
举例子：
二、数据库架构（Java自学网推荐 www.javazx.com）
1、简单的MySQL主从复制:MySQL的主从复制解决了数据库的读写分离，并很好的提升了读的性能，其图如下：
其主从复制的过程如下图所示：
但是，主从复制也带来其他一系列性能瓶颈问题：
那问题产生总得解决的，这就产生下面的优化方案，一起来看看。
2、MySQL垂直分区如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案，而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。经过垂直分区后的数据库架构图如下：
然而，尽管业务之间已经足够独立了，但是有些业务之间或多或少总会有点联系，如用户，基本上都会和每个业务相关联，况且这种分区方式，也不能解决单张表数据量暴涨的问题，因此为何不试试水平分割呢？
3、MySQL水平分片（Sharding）这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下：
如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示：
①单库单表单库单表是最常见的数据库设计，例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。
②单库多表随着用户数量的增加，user表的数据量会越来越大，当数据量达到一定程度的时候对user表的查询会渐渐的变慢，从而影响整个DB的性能。如果使用mysql, 还有一个更严重的问题是，当需要添加一列的时候，mysql会锁表，期间所有的读写操作只能等待。 可以通过某种方式将user进行水平的切分，产生两个表结构完全一样的user_0000,user_0001等表，user_0000 + user_0001 + …的数据刚好是一份完整的数据。
③多库多表随着数据量增加也许单台DB的存储空间不够，随着查询量的增加单台数据库服务器已经没办法支撑。这个时候可以再对数据库进行水平区分。
四、分库分表规则
设计表的时候需要确定此表按照什么样的规则进行分库分表。例如，当有新用户时，程序得确定将此用户信息添加到哪个表中；同理，当登录的时候我们得通过用户的账号找到数据库中对应的记录，所有的这些都需要按照某一规则进行。 路由 通过分库分表规则查找到对应的表和库的过程。如分库分表的规则是user_id mod 4的方式，当用户新注册了一个账号，账号id的123,我们可以通过id mod 4的方式确定此账号应该保存到User_0003表中。当用户123登录的时候，我们通过123 mod 4后确定记录在User_0003中。 分库分表产生的问题，及注意事项
1. 分库分表维度的问题假如用户购买了商品,需要将交易记录保存取来，如果按照用户的纬度分表，则每个用户的交易记录都保存在同一表中，所以很快很方便的查找到某用户的 购买情况，但是某商品被购买的情况则很有可能分布在多张表中，查找起来比较麻烦。反之，按照商品维度分表，可以很方便的查找到此商品的购买情况，但要查找 到买人的交易记录比较麻烦。 所以常见的解决方式有：
联合查询基本不可能，因为关联的表有可能不在同一数据库中。
3. 避免跨库事务避免在一个事务中修改db0中的表的时候同时修改db1中的表，一个是操作起来更复杂，效率也会有一定影响。
4. 尽量把同一组数据放到同一DB服务器上例如将卖家a的商品和交易信息都放到db0中，当db1挂了的时候，卖家a相关的东西可以正常使用。也就是说避免数据库中的数据依赖另一数据库中的数据。
5.一主多备在实际的应用中，绝大部分情况都是读远大于写。Mysql提供了读写分离的机制，所有的写操作都必须对应到Master，读操作可以在 Master和Slave机器上进行，Slave与Master的结构完全一样，一个Master可以有多个Slave,甚至Slave下还可以挂 Slave,通过此方式可以有效的提高DB集群的 QPS. 所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。 此外，可以看出Master是集群的瓶颈，当写操作过多，会严重影响到Master的稳定性，如果Master挂掉，整个集群都将不能正常工作。 所以
五、MySQL使用为什么要分库分表
可以用说用到MySQL的地方,只要数据量一大, 马上就会遇到一个问题,要分库分表. 这里引用一个问题为什么要分库分表呢?MySQL处理不了大的表吗? 其实是可以处理的大表的.我所经历的项目中单表物理上文件大小在80G多,单表记录数在5亿以上,而且这个表 属于一个非常核用的表:朋友关系表. 但这种方式可以说不是一个最佳方式. 因为面临文件系统如Ext3文件系统对大于大文件处理上也有许多问题. 这个层面可以用xfs文件系统进行替换.但MySQL单表太大后有一个问题是不好解决: 表结构调整相关的操作基 本不在可能.所以大项在使用中都会面监着分库分表的应用. 从Innodb本身来讲数据文件的Btree上只有两个锁, 叶子节点锁和子节点锁,可以想而知道,当发生页拆分或是添加新叶时都会造成表里不能写入数据.所以分库分表还就是一个比较好的选择了. 那么分库分表多少合适呢? 经测试在单表1000万条记录一下,写入读取性能是比较好的. 这样在留点buffer,那么单表全是数据字型的保持在800万条记录以下, 有字符型的单表保持在500万以下. 如果按 100库100表来规划,如用户业务: 500万*100*100 = 50000000万 = 5000亿记录. 心里有一个数了,按业务做规划还是比较容易的.
分布式数据库架构--排序、分页、分组、实现
六、最近研究分布式数据库架构，发现排序、分组及分页让着实人有点头疼。现把问题及解决思路整理如下。
1.多分片（水平切分）返回结果合并（排序）①Select + None Aggregate Function的有序记录合并排序解决思路：对各分片返回的有序记录，进行排序去重合并。此处主要是编写排序去重合并算法。
②Select + None Aggregate Function的无序记录合并解决思路：对各分片返回的无序记录，进行去重合并。
比如：
select count(*) from userselect count(deptno) from user;select count(distinct deptno) from user;2.多分片（水平切分）返回结果分页解决思路：合并各分片返回结果，逻辑分页。
优点： 实现简单。
缺点： 数据量越大，缓存压力就越大。
分片数据量越大，查询也会越慢。
3.多分片（水平切分）查询有分组语法的合并①Group By Having + None Aggregate Function时解决思路：去掉having AF条件查询各分片，然后把数据放到一张表里。再用group by having 聚合函数查询。
4.分布式数据库架构--排序分组分页参考解决方案对 于分布式数据库架构来说，排序、分页、分组一直就是一个比较复杂的问题。避免此问题需要好好地设计分库、分表策略。同时根据特定的场景来解决问题。也可以 充分利用海量数据存储（Hadoop-HDFS|Hive|HBse）、搜索引擎（Lucene|Solr）及分布式计算（MapReduce）等技术来 解决问题。别外，也可以用NoSQL技术替代关系性数据库来解决问题，比如MogonDB edis。
即使爬到最高的山上，一次也只能脚踏实地地迈一步。评论0
加载中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答1
回答0
回答0
回答
