首先我们要知道分库、分表都是干啥的，本文主角还是我们的MySQL为第一视角。首先从字面意思来看：
不管是为了满足业务发展的需要，还是为了提升自己的竞争力，关系数据库厂商（Oracle、DB2、MySQL 等）在优化和提升单个数据库服务器的性能方面也做了非常多的技术优化和改进。但业务发展速度和数据增长速度，远远超出数据库厂商的优化速度，尤其是互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。
转转二手交易网 —— 把家里不用的东西卖了变成钱，一个帮你赚钱的网站。由腾讯与 58 集团共同投资。为海量用户提供一个有担保、便捷的二手交易平台。转转是 2015 年 11 月 12 日正式推出的 APP，遵循“用户第一”的核心价值观，以“让资源重新配置，让人与人更信任”为企业愿景，提倡真实个人交易。
所谓的性能优化，一般针对的是MySQL查询的优化。既然是优化查询，我们自然要先知道查询操作要经过哪些环节，然后思考可以在哪些环节进行优化。
为了解决上述问题，专家们设计出更加利于管理数据的东西——数据库，它能更有效的管理数据。数据库的水平是衡量一个程序员水平的重要指标。数据库存储介质：磁盘和内存。
本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。
通俗地讲表分区是将一大表，根据条件分割成若干个小表。mysql5.1开始支持数据表分区了。 如：某用户表的记录超过了600万条，那么就可以根据入库日期将表分区，也可以根据所在地将表分区。当然也可根据其他的条件分区。
之前一篇文章已经谈到了数据库集群之主从集群也就是读写分离，也提到了读写分离其实只是分担了访问的压力，但是存储的压力没有解决。
MySQL 的慢查询日志记录的内容是：在 MySQL 中响应时间超过参数 long_query_time（单位秒，默认值 10）设置的值并且扫描记录数不小于 min_examined_row_limit（默认值0）的语句。
📒博客首页：蔚说的博客 🎉欢迎关注🔎点赞👍收藏⭐️留言📝 🙏作者水平很有限，如果发现错误，求告知，多谢！ 🌺有问题可私信交流！！！ （千鋒教育讀書筆記）僅供學習交流 MySQL操作語言-DDL DDL-數據庫定義 查詢數據庫 創建數據庫 修改數據庫-修改數據庫字符集 刪除數據庫 使用/切換數據庫 創建表 查詢數據表 查詢表結構 刪除數據表 修改數據表 （千鋒教育讀書筆記） DDL-數據庫定義 查詢數據庫 顯示當前MySQL中的數據庫列表 show databases; 顯示指定名稱的數據庫的創建
之前我们讲过架构设计的一些原则，和架构设计的方法论，今天我们谈谈高性能数据库集群的设计与应用。
一般情况下我们创建的表对应一组存储文件，使用MyISAM存储引擎时是一个.MYI和.MYD文件，使用Innodb存储引擎时是一个.ibd和.frm（表结构）文件。
大家好，我是陆金所数据库团队的负责人王英杰。这次的分享主要集中在陆金所去O在线换库的技术特点上，之后详细给大家剖析陆金所设计的在线换库方案以及方案如何在一个庞大的金融系统里通过多个团队的紧密配合稳妥落地。
本文会分享陆金所在线换库的全过程，详细剖析陆金所设计的在线换数据库方案，整套方案又是如何在一个复杂庞大的金融系统里，通过多团队紧密配合稳妥落地。希望阅读本文之后，能够让大家深入了解金融核心系统去 Oracle 的难点和风险，并给想去 Oracle 但是不敢落地实施的同学提供真正的实战案例解决思路。
技术选型是由技术方向和业务场景 trade-off 决定的，脱离业务场景来说技术选型是没有任何意义的，所以本文只是阐述了伴鱼技术团队数据库选型的过程，这并不是 MySQL、MongoDB 和 TiDB 之间直接的比较，只能说明 TiDB 更适合伴鱼的业务场景和技术规划，另外由于 TiDB 是非常新的数据库技术，所以这也能体现出伴鱼技术团队对新技术的态度、技术后发优势的理解、成本与效率的衡权和技术生态与红利的思考。
大多数情况下，应用架构设计不好，引入什么新存储，引入什么DDD，治标不治本，都是扯淡。
当我们的数据量比较大（没接触过）就会考虑一下分库分表的策略。当然分库分表又分为多种策略：
文章集中整理总结mysql分库分表开源产品，分布式数据库的设计，以及实际应用案例等相关内容，部分附上本文作者实际应用过程中的理解。
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的磁盘、IO、系统开销，甚至性能上的瓶颈，而一台服务的资源终究是有限的，因此需要对数据库和表进行拆分，从而更好的提供数据服务。
Apache Hive 是基于 Apache Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并且提供了 Hive SQL 进行查询和分析，在离线数仓中被广泛使用。
这个问题是一个粉丝给我提的，我觉得挺有意(KENG)思(B)! 于是，今天我们就来谈一谈，这个自增主键用完了该怎么办！
数据库切分概述 数据切分概述 OLTP和OLAP 在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类 型：联机事务处理（OLTP）和联机分析处理（OLAP）。 联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间 内给出处理结果。 联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强 决策分析功能。 对于两者的主要区别可以
有网友对《假如让你来设计数据库中间件》一文中，数据库中间件仅仅支持四类SQL存有疑问： partition key普通查询 partition key上的IN查询 非partition key上的查询 有限功能的排序+分页查询 这四类SQL就能满足公司业务的需求么，这个结论是怎么来的？ 看来《假如让你来设计数据库中间件》的架构结论并不能让刨根究底的网友们满意，于是把13年底，需求调研的过程细节也说一说，作为一个一线架构师，治学还是得严谨。 一、业务侧的分库后SQL需求 先说结论，通过初步的调研，发现58各
分库分表推荐Spring Cloud Alibaba+Seata+Shardingsphere
背景 原大众点评的订单单表早就已经突破两百G，由于查询维度较多，即使加了两个从库，优化索引，仍然存在很多查询不理想的情况。去年大量抢购活动的开展，使数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求。随着这些问题越来越突出，订单数据库的切分就愈发急迫了。 这次切分，我们的目标是未来十年内不需要担心订单容量的问题。 垂直切分 先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，本文就不
通过这个图，就大概可以理解业务需求了，短链平台就是将商家的长链转换为短链，商家决定向哪个平台投放广告，我们平台做出一个
作者简介 初八，携程资深研发经理，专注于订单后台系统架构优化工作；JefferyXin，携程高级后端开发专家，专注系统性能、业务架构等领域。 一、背景 随着机票订单业务的不断增长，当前订单处理系统的架构已经不能满足日益增长的业务需求，系统性能捉襟见肘，主要体现在以下方面： 数据库CPU资源在业务高峰期经常达到50%以上，运行状况亮起了黄灯 磁盘存储空间严重不足，需要经常清理磁盘数据腾挪可用空间 系统扩容能力不足，如果需要提升处理能力只能更换配置更好的硬件资源 因此我们迫切需要调整和优化机票订单数据库
初八，携程资深研发经理，专注于订单后台系统架构优化工作；JefferyXin，携程高级后端开发专家，专注系统性能、业务架构等领域。
索引是一种特殊的文件,它们包含着对数据表里所有记录的引用指针，相当于书本的目录。其作用就是加快数据的检索效率。常见索引类型有主键、唯一索引、复合索引、全文索引。
由 Oracle 维护的官方文档为您提供了安装、配置和与 MySQL 交互所需的知识。本书作为该文档的伴侣，帮助您了解如何最好地利用 MySQL 作为强大的数据平台来满足您的用例需求。
MySQL的数据量到达一定的限度之后，它的查询性能会下降，这不是调整几个参数就可以解决的，如果我们想要自己的数据库继续保证一个比较高的性能，那么分库分表在所难免。
1） 应用间耦合严重。系统内各个应用之间不通，同样一个功能在各个应用中都有实现，后果就是改一处功能，需要同时改系统中的所有应用。这种情况多存在于历史较长的系统，因各种原因，系统内的各个应用都形成了自己的业务小闭环；
1） 应用间耦合严重 。系统内各个应用之间不通，同样一个功能在各个应用中都有实现，后果就是改一处功能，需要同时改系统中的所有应用。这种情况多存在于历史较长的系统，因各种原因，系统内的各个应用都形成了自己的业务小闭环；
本文着重介绍sharding的基本思想和理论上的切分策略 参考地址：http://blog.csdn.net/bluishglc/article/details/6161475 要点总结 基本思想： 把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。 多数系统会将垂直切分和水平切分联合使用，先对系统做垂直切分，再针对每一小搓表的情况选择性地做水平切分。从而将整个数据库切分成一个分布式矩阵。 1.垂直切分： 对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用
公众号改版后文章乱序推荐，希望你可以点击上方“Java进阶架构师”，点击右上角，将我们设为★“星标”！这样才不会错过每日进阶架构文章呀。
首先数据库技术发展的基础还是在业务推动的背景下，能够实现相关的技术保障。业务需求的提升必然会在数据量，访问量等方面有更高的要求，而映射到数据库层面就不是简单的扩容和添加资源了，我们有时候更需要弹性，需要快速实现，需要更高的性能。这些都是摆在我们面前的问题，而不仅仅是DBA团队。 所以早期的很多数据库，从一主一从，一主多从的架构，逐步演变到了读写分离，分库分表，然后就是分布式。而同时从很多层面来说，行业内的方案真是百花齐放，记得前几天还和同事聊，说如果对比一下Oracle和MySQL,
缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。 解决什么问题？ 回答：当mysql单表的数据库过大时，数据库的访问速度会下降，“数据量大”问题的常见解决方案是“水平切分”。 mysql常见的水平切分方式有哪些？ 回答：分库分表，分区表 什么是mysql的分库分表？ 回答：把一个很大的库（表）
小伙伴想精准查找自己想看的MySQL文章？喏 → MySQL专栏目录 | 点击这里
Mysql中事务的隔离级别分为四大等级：读未提交（READ UNCOMMITTED）、读提交 （READ COMMITTED）、可重复读 （REPEATABLE READ）、串行化 （SERIALIZABLE）。
初学者在看到这个问题的时候，可能首先想到的是 MySQL 一张表到底能存放多少条数据？
北冥有 Data，其名为鲲，鲲之大，一个 MySQL 放不下。千万量级的数据，用 MySQL 要怎么存？
缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。
MySQL中的数据用各种不同的技术存储在文件（或者内存）中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。
在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
| 导语：生活中的问题有时“难得糊涂”，但技术问题，一是一二是二，忌讳模糊的似是而非的答案，也忌讳一刀切的简单结论。我们常常听到一些关于MySQL的说法，比如“读不加锁”，比如“单表数据要小于1000万”，比如“DDL会锁表”等，比如“单表的索引数量应该小于X个”，如果不加思考和测试就直接全盘接受，就可能犯错误，而DB上的错误又非常“昂贵”，我们应该尽量避免。所以有了想法写10-20篇文章，来思考下这些常见说法是否正确，或者说在什么条件下是正确的。水平所限，也可能文章中会有错误，欢迎大家一起探讨。第1篇文章首先分析下“读不加锁”这种说法是否正确呢？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
