MySQL如何实现分库分表，如何提高查询效率

记得有一次，我在做项目的时候，数据库的数据量已经捉襟见肘，直到无法容纳。
那一刻，我急得像热锅上的蚂蚁。
我兼职到那天晚上，突然想出了一个办法：数据库和表分开。
我尝试从一个大表中提取一些数据并将其拆分为较小的表。
结果嘿嘿，数据库的压力立马就减轻了。
库表共享听起来很复杂，但实际上就是将一个大的数据库分成很多较小的数据库，每个较小的数据库负责一段数据。
这就像把一个超市分成许多个较小的超市一样。
每个小超市只销售有限部分的产品，管理起来更加容易。
但是数据库一旦分区表，查询就变得困难，必须借助一些中间件来帮助。
我尝试使用 MyCat，它非常棒，可以帮助我自动将查询分发到不同的数据库。
当时，我发现可以将查询分成几十个较小的查询并同时执行它们，这是非常高效的。
然而，这仅涉及调查问卷的有效性。
还需要考虑许多其他细节，例如数据一致性、分布式事务等。
等等，我突然想到，如果数据库大了，我们还应该考虑分布式数据库吗？这确实是个问题。

## 大数据量用户列表分页查询，如何才能又快又稳？

说实话，这个问题相当复杂，但说白了，无非就是几点。
需要对用户列表页面进行快速稳定的控制。

我们先来说说“空间换时间”。
诀窍是预先做好工作，而不必在实际检查时进行计算。

1 .预览用户组关系。
想想看，一个用户属于多个组，旧的链接表查找速度极其慢。
您必须提前创建用户-用户组映射表，并将用户组ID直接映射到用户表。
检查时，直接使用LIKE '%Group ID%'（最好配合全文索引优化）或者JSON函数（如MySQL的JSON_CONTAINS），它会立即输出，而不会触及其他表。
我已经尝试过这个技巧，当数据量很大时，它确实有效。

2 表存储按状态划分。
员工状态是高频检查，例如在职或辞职。
直接按状态切表，如user_active、user_inactive。
要查看是否有工作人员，只需前往 user_active 即可，无需扫描整个表。
上次我测试时，拆分表后查询速度至少快了 5 0%。

3 物化视图存储公共查询缓存。
某些固定条件的组合特别常用，例如“用户组A+就业状况”。
您可以创建一个物化视图，每天早上刷新它并在白天直接检查和读取结果。
我见过一些公司使用这种方法，他们的查询响应时间减少了 9 0%。

就 NoSQL 数据库而言，Elasticsearch 相当不错。

1 .数据同步和索引。
需要将用户数据同步到ES，使用Logstash或者Canal，然后在ES上建立倒排索引。
例如，user_group、username、status等字段支持快速关键字搜索。
上次我检查组为“A”并且正在工作的用户时，ES直接通过索引找到了他们，花费了不到1 秒的时间。

2 网站优化。
ES默认是按/size分页，但是检查深页特别慢。
您应该使用search_after 或scrollAPI 来代替。
search_after适合实时分页，滚动适合分组导出。
尝试 search_after 和深度结帐停止工作。

3 聚合查询取代了连接表。
ES集合框架可以直接在索引中进行计算。
例如，要统计每个用户组中的活跃用户数，ES 可以自己完成此操作，而无需使用 GROUPBY。
上次我用这个方法进行统计，比传统方法快了3 倍。

最后是混合解决方案。
根据业务灵活组合。

1 .频繁写入，稳定读取，数据与ES同步，ES充分利用。
关系数据库必须进行复制。
我见过公司这样做，写作压力降低了7 0%。

2 多读少写，保证稳健的稳定性。
使用关系数据作为基础数据并使用ES 用于复杂问题。
我尝试了一下，考虑到灵活性和性能。

说白了就是数据存储结构、查询方式、数据库选择都需要优化。
预处理节省实时计算，ES提高查询效率，混合方案灵活。
具体选择取决于数据量、查询频率、一致性要求。

MySQL如何实现跨数据库查询_有哪些限制和技巧？

上周有客户问我MySQL跨库查询的问题，我给他详细解释了。

首先，跨库查询主要有两种方式。
第一种是使用“数据库名.表名”的格式。
这种方法比较简单，就像SELECT FROM db1 .table1 , db2 .table2 WHERE db1 .table1 .id = db2 .table2 .tid这样的SQL语句一样。
但这种方法有一个限制，即两个数据库必须位于同一台MySQL服务器上，并且用户必须同时拥有访问两个数据库的权限。

第二种方法是使用FEDERATED引擎。
这就像创建远程表的本地映射。
例如：CREATE TABLE federated_table(id INT NOT NULL AUTO_INCRMENT, name VARCHAR(3 0), PRIMARY KEY(id)) ENGINE=FEDERATED CONNECTION='mysql://remote_user:password@remote_host:3 3 06 /db_name/table_name';
该方法可以跨服务器查询数据，但性能较差，尤其是数据量较大或数据写入时 经常。
而且不支持交易，配置和维护都比较复杂，必须注意安全性。

在实际应用中，跨库查询可能会遇到一些问题，比如无法直接查询不同服务器的数据、权限控制复杂、性能问题、难以保证事务一致性、备份恢复复杂度增加等。

要优化跨库查询，有几个实用的技巧。
例如，合并数据库设计、使用视图简化查询、中间层聚合数据、定期同步数据、使用分库分表中间件，如MyCat、ShardingSphere等。

无论如何，这取决于你。
这些方法中的每一种都有其自身的优点和缺点。
使用哪一种取决于您的实际需要。
我还在想这个问题。
如果您还有其他问题，请随时问我。