个人的观点，这种大表的优化，不一定上来就要分库分表，因为表一旦被拆分，开发、运维的复杂度会直线上升，而大多数公司是欠缺这种能力的。所以MySQL中几百万甚至小几千万的表，先考虑做单表的优化。
单表优化
单表优化可以从这几个角度出发：
表分区：MySQL在5.1之后才有的，可以看做是水平拆分，分区表需要在建表的需要加上分区参数，用户需要在建表的时候加上分区参数；分区表底层由多个物理子表组成，但是对于代码来说，分区表是透明的；SQL中的条件中最好能带上分区条件的列，这样可以定位到少量的分区上，否则就会扫描全部分区。
读写分离：最常用的樱桐优化手段，写主库读从库；
增加缓存：主要的思想就是减少对数据库的访问，缓存可以在整个架构中的很多地方，比如：数据库本身有就缓存，客户端缓存，数据库访问层对SQL语句的缓存，应用程序内的缓存，第三方缓存（如Redis等）；
字段设计：单表不要有太多字段；VARCHAR的长度尽量只分配真正需要的空间；尽量使用TIMESTAMP而非DATETIME；避免使用NULL，可以通过设置默认值解决。
索引优化：索引不是越多越好，针对性地建立索引，索引会加速查询，但是对新增、修改、删除会造成一定的影响；值域很少的字段不适合建索引；尽量不用UNIQUE，不要设置外键，由程序保证；
SQL优化：尽量使用索引，也要保证不要因为错误的写法导致索引失效；比如：避免前导模糊查询，避免隐式转换，避免等号左边做函数运算，in中的元素不宜过多等等；
NoSQL：有一些场景，可以抛弃MySQL等关系型数据库，拥抱NoSQL；比如：统计类、日志类、弱结构化的数据；事务要求低的场景。
表拆分
数据量进一步增大的时候，就不得不考虑表拆分的问题了：
垂直拆分：垂直拆分的意思就是把一个字段较多的表，拆分成多个字段较少的表；上文中也说过单表的字段不宜过多，如果初期的表结构设计的就很好，就不会有垂直拆分的问题了；一般来说，MySQL单表的字段最好不要超过二三十个。
水平拆分：就是我们常说的分库分表了；分表，解决了单表数据过大的问题，但是毕竟还在同一台数据库服务器上，所以明颂裂IO、CPU、网络方面的压力，并不会得到彻底的缓解，这个可以通过分库来解决。水平拆分优点很明显，可以利用多台数据库服务器的资源，提高了系统的负载能力；缺点是逻辑会变得复杂，跨节点的数据关联性能差，维护难度大（特别是扩容的时候）。
希望我的回答，能够帮助到你！我将持续分享Java开发、架构激闭设计、程序员职业发展等方面的见解。
㈡ 如何设计一个带有多级别的数据库表结构
表结构如下：
ID(int，主键，自动生成)
name(varchar20，省名或城市名)
parentID(int，父ID：为省时此列为0，为市时此列对应省的ID列的指)
sortNum(int，排序编号：可以按照编号值有小到大排列)
举例：
ID name parentID sortNum
1 山东 0 0
2 浙江 0 0
3 济南 1 0
4 青岛 1 0
5 杭州 2 0
....
㈢ 大型数据库的设计原则与开发技巧
随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧
一 成立数据小组
大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成
数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系颤腔统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库（如果存在旧系统）的分析及数据转换 数据库设计的审核 控制及必要调整
二 设计原冲迟则
规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询
控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计
库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复
并发控制 设计中应进行并发控制 即对于同一个库表 在茄判衫同一时间只有一个人有控制权 其他人只能进行查询
必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息
数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求
头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改（可由管理软件自动完成） 并通知相关的开发人员 以便进行相应的程序修改
三 设计技巧
分类拆分数据量大的表 对于经常使用的表（如某些参数表或代码对照表） 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率
索引设计 对于大的数据库表 合理的索引能够提高整个数据库的操作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的操作效率
数据操作的优化 在大型数据库中 如何提高数据操作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔操作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统操作的核心 有可能在操作时被其他进程锁定 因而使整个事务操作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O操作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O操作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表操作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop操作再进行重建
数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整
必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率
避免长事务 对单个大表的删除或插入操作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序操作共同构成的长事务（如银行交易系统的日终交易） 可以由一系列操作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务
适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能
lishixin/Article/program/SQL/201311/16498
㈣ mysql千万或者上亿的数据怎么设计数据库
单表一亿？还是全库1亿？
1.首先可以考虑业务层面优化，即垂直分表。
垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。
如有多种业务类型，每种业务类型入不同的表，table1,table2,table3.
如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月记录。
2.架构上的优化，即水平分表。
水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。
如按照id分表，末尾是0-9的数据分别插入到10个表里面。
可能你要问，这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异，都是按字段的值来分表。
实际上，水平分表现在最流行的实现方式，是通过水平分库来实现的。即刚才所说的10个表，分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来，实现高性能。
最常见的解决方案是cobar，这个帖子介绍的比较完善，可以看看。
http://blog.csdn.net/shagoo/article/details/8191346
cobar的逻辑层次图：
不过这种分库方式也是有一定局限性的，需要应用程序做相应的配合，比如说分库的情况下，虽然可以实现跨库查询，但是不能进行相关的group by计算。
另外，之前关于水平分表的实现方式，也可以通过表分区来实现。
mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。
分区只需要一次本地数据迁移的操作。
而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。
㈤ 数据量大，列比较多，请问数据库表该如何设计
基本的建立主键，索引什么的，我就不说了，
表设计可以采取拆分表的方式
纵向拆分表：根据字段拆分为多个表，每个表都有关联字段，可以将他们关联起来
（例如：订单表，几个根据字段拆分的表中都有1个订单号字段）
横向拆分表：不知道你具体什么数据，假定其中有时间字段，根据时间来拆分
（例如：1年有12个月，1个月的数据放入一个表中）