企业门户网站费用网页打不开显示证书错误是怎么回事

企业门户网站费用,网页打不开显示证书错误是怎么回事,天津百度首页优化排名,网站卖给做网站的目录 1、分库分表分区 1.1、联系 1.2、对比 2、分区#xff08;Partitioning#xff09; 2.1、介绍 2.2、核心原理 2.3、常见分区类型 2.4、分区管理命令 3、分表#xff08;Table Sharding#xff09; 3.1、介绍 3.2、使用原因 3.3、分片策略设计 3.4、MyBa…目录1、分库分表分区1.1、联系1.2、对比2、分区Partitioning2.1、介绍2.2、核心原理2.3、常见分区类型2.4、分区管理命令3、分表Table Sharding3.1、介绍3.2、使用原因3.3、分片策略设计3.4、MyBatis 分表4、分库Database Sharding4.1、分库原因4.2、分库分表组合模式4.3、架构5、最佳实践前言单机 MySQL 的瓶颈如下关于分库、分表和读写分离的架构图如下所示1、分库分表分区1.1、联系技术物理位置逻辑视图是否跨实例分区Partitioning同一表、同一库、同一 MySQL 实例仍是一个表否分表Table Sharding多个表如user_0,user_1同一库应用需知道多个表否分库Database Sharding多个数据库如db_0,db_1可能跨 MySQL 实例应用需路由到不同库是核心思想分区数据库内部优化分库分表应用层或中间件实现的分布式架构1.2、对比能力分区分表分库是否跨实例❌❌✅应用是否感知❌透明✅需拼表名✅需路由突破单机瓶颈❌❌仍在单库✅支持跨分片查询✅自动裁剪❌❌需中间件模拟扩容难度低高极高典型工具MySQL 原生应用层ShardingSphere, Vitess2、分区Partitioning2.1、介绍MySQL原生支持将一个大表的数据物理拆分到多个“分区”中但逻辑上仍是一个表数据库内置能力。开发人员在数据操作时仍然是对这个整体大表进行操作之后由数据库底层内部去寻找对应的分区进行操作这样在数据操作时可以只对特定分区操作以提高效率存储时也可以将不同分区的物理文件分开存放。2.2、核心原理物理存储分离每个分区是一个独立.ibd文件逻辑视图统一应用仍操作一个表名查询自动裁剪优化器只扫描相关分区2.3、常见分区类型1.RANGE 分区按范围如下所示-- 按年份分区 CREATE TABLE sales ( id BIGINT, sale_date DATE, amount DECIMAL(10,2) ) PARTITION BY RANGE (YEAR(sale_date)) ( PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024), PARTITION p2024 VALUES LESS THAN (2025), PARTITION p_future VALUES LESS THAN MAXVALUE ); -- 查询自动裁剪 EXPLAIN SELECT * FROM sales WHERE sale_date 2023-06-01; -- 只扫描 p2023 分区(2) LIST 分区按枚举值如下所示-- 按地区分区 CREATE TABLE users ( id BIGINT, region VARCHAR(10) ) PARTITION BY LIST COLUMNS(region) ( PARTITION p_north VALUES IN (BJ, TJ), PARTITION p_south VALUES IN (GZ, SZ), PARTITION p_west VALUES IN (CD, XA) );(3) HASH 分区均匀分布如下所示-- 按 user_id 均匀分布到 4 个分区 CREATE TABLE orders ( id BIGINT, user_id BIGINT ) PARTITION BY HASH(user_id) PARTITIONS 4;(4) KEY 分区类似 HASH支持多列如下所示PARTITION BY KEY(user_id, order_type) PARTITIONS 8;2.4、分区管理命令-- 添加新分区 ALTER TABLE sales ADD PARTITION ( PARTITION p2025 VALUES LESS THAN (2026) ); -- 删除旧分区秒级 ALTER TABLE sales DROP PARTITION p2022; -- 重建分区整理碎片 ALTER TABLE sales REBUILD PARTITION p2023;✅ 优点对应用透明SQL 不用改SELECT * FROM logs WHERE create_time 2024-01-01自动只查p2024提升查询性能分区裁剪Partition Pruning方便数据管理ALTER TABLE logs DROP PARTITION p2023;快速删除旧数据❌ 缺点仍在单机无法突破单 MySQL 实例的 CPU/内存/磁盘瓶颈分区数有限通常建议 100 个分区不支持所有引擎仅 InnoDB、MyISAM 支持 适用场景单表过大 1000万行但总数据量未超单机容量按时间冷热分离如日志、订单需要快速删除历史数据3、分表Table Sharding3.1、介绍将一张大表拆成多张结构相同的表应用层拆分。如下所示3.2、使用原因为什么需要分表InnoDB 单表建议 5000万行B树深度增加表锁/元数据锁竞争DDL 操作阻塞如user_0, user_1, user_2, user_3如何路由通常用分片键Shard Key 取模/哈希决定数据存哪张表。如下所示示例按 user_id 分 4 张表// Java 伪代码 public String getTableName(Long userId) { int tableIndex (int) (userId % 4); return user_ tableIndex; } // 查询用户 String sql SELECT * FROM getTableName(userId) WHERE id ?;3.3、分片策略设计1.分片键选择字段优点缺点user_id用户数据聚集热点用户问题order_id均匀分布无法按用户查订单tenant_id多租户隔离租户数据不均最佳实践选高频查询字段作为分片键2.分片算法// 取模简单但扩容难 int tableIndex userId % tableCount; // 一致性哈希扩容友好 HashFunction hash Hashing.murmur3_32(); int bucket hash.hashLong(userId).asInt() Integer.MAX_VALUE; int tableIndex bucket % tableCount;3.4、MyBatis 分表步骤 1定义分表路由Component public class TableShardingRouter { private static final int TABLE_COUNT 4; public String getTableName(String baseName, Long shardKey) { int index (int) (shardKey % TABLE_COUNT); return baseName _ index; } }步骤 2MyBatis 动态表名!-- UserMapper.xml -- select idselectById resultTypeUser SELECT * FROM ${tableName} WHERE id #{id} /select步骤 3Service 层调用Service public class UserService { Autowired private TableShardingRouter router; Autowired private UserMapper userMapper; public User getUser(Long userId) { String tableName router.getTableName(user, userId); return userMapper.selectById(tableName, userId); } }优点突破单表性能瓶颈InnoDB 单表建议 5000万行实现简单无需中间件缺点应用强耦合每个 SQL 都要拼表名无法跨表 JOIN / 聚合select count(*) from user_* 需查 4 次再 sum扩容困难从 4 表扩到 8 表需迁移一半数据适用场景单库能扛住但单表太大查询基本都带分片键如 where user_id ?4、分库Database Sharding4.1、分库原因为什么需要分库单机资源耗尽CPU/内存/IO连接数瓶颈max_connections多租户数据隔离需求4.2、分库分表组合模式模式 1库内分表推荐4 个库 × 每库 16 张表 64 分片优点减少数据库连接数模式 2仅分库4 个库 × 每库 1 张表优点简化表结构计算公式总分片数 库数量 × 表数量分片ID hash(shard_key) % 总分片数库名 分片ID / 表数量表名 分片ID % 表数量4.3、架构如下所示是什么将数据分散到多个数据库实例可能在不同机器真正的分布式。如db_0IP: 10.0.0.1db_1IP: 10.0.0.2通常分库 分表一起用如db_0.user_0, db_0.user_1db_1.user_0, db_1.user_1架构图Application│├── Router (ShardingSphere / MyCat / 自研)│ ││ ├── db_0 (10.0.0.1)│ │ ├── user_0│ │ └── user_1│ ││ └── db_1 (10.0.0.2)│ ├── user_0│ └── user_1优点水平扩展突破单机资源限制CPU/内存/连接数高可用一个库挂了其他库仍可用隔离性租户/业务线数据物理隔离缺点复杂度飙升跨库事务需 Seata/TCC跨库 JOIN需应用层聚合全局 ID需 Snowflake/Leaf运维成本高备份、监控、扩容都变复杂适用场景海量数据 1TB超高并发 1万 QPS多租户 SaaS 系统5、最佳实践1.不要过早分库分表→ 先优化 SQL、加索引、读写分离、缓存2.分片键至关重要→ 选高频查询字段如 user_id避免热点3.避免跨分片操作→ 设计时让关联数据落在同分片如订单 订单项都按 user_id 分4.全局 ID 必须趋势递增→ 避免 UUID 导致 InnoDB 性能下降;总结结论分区是“治标”分库分表是“治本”。90% 的系统用好分区 读写分离 缓存就足够了只有真正遇到单机瓶颈才考虑分库分表。参考文章1、【MySQL】之分区、分库、分表