Mysql最佳实践-CSDN博客

本文链接：https://blog.csdn.net/a5192041/article/details/147400526

生产环境安全修改MySQL表名

方案一：表重命名

操作简单，适合低峰期无业务数据产生的系统。

阶段一：准备工作

选择低峰期操作：在业务低峰期（如凌晨）执行变更

备份数据：

CREATE TABLE old_table_backup_YYYYMMDD LIKE original_table;
INSERT INTO old_table_backup_YYYYMMDD SELECT * FROM original_table;

通知相关团队：告知开发、运维、DBA等团队变更计划

阶段二：创建新表并同步数据

创建新表结构：

CREATE TABLE new_correct_name LIKE original_table;

同步数据：

INSERT INTO new_correct_name SELECT * FROM original_table;

阶段三：切换表名（关键步骤）

使用原子性RENAME操作：
```
RENAME TABLE original_table TO new_table;
```
这个操作是原子性的，不会造成数据丢失

阶段四：后续处理

更新应用程序：
- 部署使用新表名的代码版本
- 确保所有SQL查询已更新为新表名

方案二：代码兼容新旧表

适合业务不能中断的系统。

阶段一：做好代码兼容

try{
    //使用新表读写数据
} catch(表不存在 e){
    //使用旧表读写数据
}

阶段二：部署代码

对兼容的代码进行发布部署。

阶段三：备份数据

选择低峰期操作：在业务低峰期（如凌晨）执行变更

备份数据：

CREATE TABLE old_table_backup_YYYYMMDD LIKE original_table;
INSERT INTO old_table_backup_YYYYMMDD SELECT * FROM original_table;

通知相关团队：告知开发、运维、DBA等团队变更计划

阶段四：切换表名（关键步骤）

使用原子性RENAME操作：
```
RENAME TABLE original_table TO new_table;
```
这个操作是原子性的，不会造成数据丢失

ShardingSphere对Mysql分库分表和 Elasticsearch 在分页查询时的性能对比和底层区别

先说性能结论：Elasticsearch 的分页机制和 ShardingSphere 分库分表框架的分页逻辑有相似之处，但 ES 的实现更高效。

1. 核心相似点：分布式查询的必然代价

第一阶段无论是 ShardingSphere 还是 Elasticsearch，在分布式环境下查询第 N 页数据时，必须让所有分片/分库返回足够的数据（如第1000页需合并 from + size 条数据）。
   第二阶段协调节点/中间件需要全局排序和过滤，最终返回正确范围内的数据。
   我以带条件查询第1000页的10条数据为例：
   ShardingSphere：向每个分库发送 LIMIT 0, 10000（from=9990, size=10），合并后取全局第9990~9999条。
   Elasticsearch：向每个分片请求本地排序后的前10000条数据（from + size），合并后取第9990~9999条。

2、Elasticsearch 的优化策略1仅传输文档元数据

ES在第一阶段仅查询文档元数据（非完整数据），各分片仅返回文档的_id和排序字段，不返回 _source，协调节点确定最终10条结果后，才去对应分片拉取完整数据，减少90%以上的数据传输量（尤其是字段很多的场景）。
ShardingSphere：每个分库分表需要返回完整的行数据，网络和内存开销大。

3、Elasticsearch 的优化策略2支持 search_after 避免深分页

使用 search_after 通过排序值定位本次需要查询的数据范围，相比每个分片需要查询第1000页的前10000条数据，search_after 只需要每个分片查询给定 search_after 值的下个满足条件的10条数据。
ShardingSphere：没有原生等效于 search_after 的机制，深度分页只能依赖 LIMIT offset, size。