漫画分库分表

“数据量大了不可怕，可怕的是不知道如何优雅地拆分。”

🎭 人物介绍

  • 架构师老王：资深数据库架构专家，精通各种分库分表方案
  • Java小明：对分库分表充满疑问的开发者
  • ShardingSphere师傅：Apache ShardingSphere的化身，国产分库分表框架代表
  • Mycat大师：Mycat框架的化身，数据库中间件专家
  • Vitess长老：Google Vitess的化身，云原生数据库集群方案
  • 数据库老爷：传统数据库的代表，见证了数据增长的痛苦

本节导言

Java小明：（困惑地）老王，我们的用户表已经有几千万条数据了，查询越来越慢，该怎么办？

架构师老王：（点头）这是典型的数据量增长问题！单表数据量过大时，我们需要考虑分库分表了。

数据库老爷：（叹气）想当年我一个人就能处理所有数据，现在…

ShardingSphere师傅：（自信地）别担心！我们有完整的分库分表解决方案，从水平拆分到垂直拆分，一应俱全！

Mycat大师：（稳重地）我擅长数据库代理，让应用无感知地使用分库分表。

Vitess长老：（淡定地）在Google，我们处理的是全球级别的数据量，云原生是未来趋势。

1. 分库分表基础概念

1.1 什么是分库分表

架构师老王：分库分表是应对大数据量和高并发的数据库优化策略，通过将数据分散到多个数据库和表中来提升性能。

分库分表后
单库单表
数据库1
数据库2
数据库3
数据库4
user_0
1250万
user_1
1250万
user_2
1250万
user_3
1250万
user_4
1250万
user_5
1250万
user_6
1250万
user_7
1250万
用户表
5000万条记录

1.2 分库分表的类型

垂直拆分 vs 水平拆分
拆分方式垂直拆分水平拆分
分库按业务模块拆分按数据特征拆分
分表按字段拆分按数据量拆分
适用场景微服务架构单表数据量过大
复杂度相对简单相对复杂

2. 主流分库分表框架对比

2.1 Apache ShardingSphere

ShardingSphere师傅：我是Apache顶级项目，提供完整的分库分表生态！

核心特性
/*** ShardingSphere配置示例*/
@Configuration
public class ShardingSphereConfig {// 数据源配置@Beanpublic DataSource dataSource() {Map<String, DataSource> dataSourceMap = new HashMap<>();dataSourceMap.put("ds0", createDataSource("jdbc:mysql://localhost:3306/db0"));dataSourceMap.put("ds1", createDataSource("jdbc:mysql://localhost:3306/db1"));// 分片规则ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();shardingRuleConfig.getTableRuleConfigs().add(getUserTableRuleConfiguration());shardingRuleConfig.getBindingTableGroups().add("user");shardingRuleConfig.setDefaultDatabaseShardingStrategyConfig(new InlineShardingStrategyConfiguration("user_id", "ds${user_id % 2}"));return ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, Collections.singleton(shardingRuleConfig), new Properties());}private TableRuleConfiguration getUserTableRuleConfiguration() {TableRuleConfiguration config = new TableRuleConfiguration("user", "ds${0..1}.user_${0..3}");config.setTableShardingStrategyConfig(new InlineShardingStrategyConfiguration("user_id", "user_${user_id % 4}"));return config;}
}
优势与劣势
优势 ✅劣势 ❌
生态完善，文档丰富学习曲线较陡峭
支持多种数据库配置相对复杂
读写分离、分布式事务性能开销相对较大
社区活跃，国产化依赖较多

2.2 Mycat

Mycat大师：我是数据库中间件的先驱，专注于透明化的数据库代理！

核心架构
<!-- Mycat server.xml配置 -->
<mycat:server xmlns:mycat="http://io.mycat/"><system><property name="serverPort">8066</property><property name="managerPort">9066</property><property name="charset">utf8</property><property name="processors">4</property><property name="processorExecutor">8</property></system><user name="mycat"><property name="password">mycat</property><property name="schemas">testdb</property></user>
</mycat:server>

<!-- schema.xml配置 -->
<schema name="testdb" checkSQLschema="false" sqlMaxLimit="100"><table name="user" primaryKey="id" dataNode="dn1,dn2,dn3,dn4" rule="mod-long" />
</schema><dataNode name="dn1" dataHost="localhost1" database="db1" />
<dataNode name="dn2" dataHost="localhost1" database="db2" />
<dataNode name="dn3" dataHost="localhost2" database="db3" />
<dataNode name="dn4" dataHost="localhost2" database="db4" />
优势与劣势
优势 ✅劣势 ❌
部署简单，上手快功能相对单一
性能优秀社区活跃度下降
对应用透明复杂查询支持有限
成熟稳定缺乏现代化特性

2.3 Vitess (Google)

Vitess长老：我来自Google，专为云原生和大规模数据处理而生！

核心特性
# Vitess Kubernetes配置
apiVersion: planetscale.com/v2
kind: VitessCluster
metadata:name: example
spec:images:vtgate: vitess/lite:latestvttablet: vitess/lite:latestcells:- name: zone1gateway:replicas: 2keyspaces:- name: commerceturndownPolicy: Immediatepartitionings:- equal:parts: 4shardTemplate:databaseInitScriptSecret:name: example-cluster-configkey: init_db.sql
优势与劣势
优势 ✅劣势 ❌
云原生架构学习成本高
超大规模数据支持生态相对较小
自动化运维主要面向MySQL
Google技术背景国内使用较少

3. 国内外优秀框架全览

3.1 国内主流框架

3.1.1 ShardingSphere (Apache)
  • 开发公司：当当网 → Apache基金会
  • GitHub Stars：19.6k+
  • 特点：功能最全面的分库分表解决方案
3.1.2 Mycat
  • 开发公司：Mycat开源社区
  • GitHub Stars：9.5k+
  • 特点：数据库中间件，性能优秀
3.1.3 TDDL (Taobao Distributed Data Layer)
  • 开发公司：阿里巴巴
  • GitHub Stars：5.5k+
  • 特点：淘宝自研，久经考验
3.1.4 Cobar
  • 开发公司：阿里巴巴
  • GitHub Stars：2.2k+
  • 特点：早期分库分表方案，Mycat前身
3.1.5 Atlas
  • 开发公司：奇虎360
  • GitHub Stars：4.1k+
  • 特点：基于MySQL-Proxy，读写分离

3.2 国外优秀框架

3.2.1 Vitess (Google)
  • 开发公司：Google
  • GitHub Stars：17.8k+
  • 特点：YouTube使用，云原生架构
3.2.2 Citus (Microsoft)
  • 开发公司：Microsoft
  • GitHub Stars：9.8k+
  • 特点：PostgreSQL分布式扩展
3.2.3 ProxySQL
  • 开发公司：ProxySQL LLC
  • GitHub Stars：5.9k+
  • 特点：高性能MySQL代理
3.2.4 MaxScale (MariaDB)
  • 开发公司：MariaDB Corporation
  • GitHub Stars：1.3k+
  • 特点：数据库代理和负载均衡
3.2.5 Gizzard (Twitter)
  • 开发公司：Twitter
  • GitHub Stars：2.3k+
  • 特点：分片框架，已停止维护

3.3 详细功能对比矩阵

国外框架对比
国内框架对比
Vitess
🇺🇸 Google
Citus
🇺🇸 Microsoft
ProxySQL
🇮🇹 ProxySQL LLC
MaxScale
🇫🇮 MariaDB
✅ 分库分表
✅ 读写分离
✅ 在线DDL
✅ 自动故障转移
✅ 备份恢复
✅ 云原生
✅ 分库分表
✅ 读写分离
✅ 分布式查询
✅ 实时分析
✅ 列式存储
✅ PostgreSQL
❌ 分库分表
✅ 读写分离
✅ 连接池
✅ 查询路由
✅ 故障转移
✅ 高性能
❌ 分库分表
✅ 读写分离
✅ 负载均衡
✅ 故障转移
✅ 监控
✅ MariaDB
ShardingSphere
🇨🇳 当当网→Apache
Mycat
🇨🇳 开源社区
TDDL
🇨🇳 阿里巴巴
Cobar
🇨🇳 阿里巴巴
Atlas
🇨🇳 奇虎360
✅ 分库分表
✅ 读写分离
✅ 分布式事务
✅ 数据脱敏
✅ 影子表
✅ 弹性伸缩
✅ 分库分表
✅ 读写分离
❌ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 负载均衡
✅ 分库分表
✅ 读写分离
✅ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 动态数据源
✅ 分库分表
✅ 读写分离
❌ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 连接池
❌ 分库分表
✅ 读写分离
❌ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 负载均衡

3.4 综合性能对比

框架QPS延迟资源消耗适用规模主要数据库
ShardingSphere中等低中等中大型MySQL/PostgreSQL/Oracle
Mycat高极低低中型MySQL
Vitess极高低高超大型MySQL
TDDL中等低中等中大型MySQL
Cobar高极低低中型MySQL
Citus高低中等大型PostgreSQL
ProxySQL极高极低低中大型MySQL
Atlas高极低低中型MySQL

3.5 生态系统与维护状态

框架社区活跃度文档质量企业支持学习成本维护状态
ShardingSphere🟢 极高🟢 优秀🟢 强🟡 中等🟢 活跃
Mycat🟡 中等🟡 一般🟡 中等🟢 低🟡 缓慢
Vitess🟢 高🟢 优秀🟢 强🔴 高🟢 活跃
TDDL🟡 中等🟡 一般🟢 强🟡 中等🟡 内部
Cobar🔴 低🔴 较差🔴 弱🟢 低🔴 停止
Citus🟢 高🟢 优秀🟢 强🟡 中等🟢 活跃
ProxySQL🟢 高🟢 优秀🟢 强🟡 中等🟢 活跃
Atlas🟡 中等🟡 一般🟡 中等🟢 低🟡 缓慢

3.6 企业应用案例

国内知名企业使用情况
框架知名用户应用场景
ShardingSphere京东、滴滴、哔哩哔哩、转转电商、出行、视频、二手交易
Mycat阿里云、腾讯云、华为云云数据库服务
TDDL淘宝、天猫、支付宝电商、支付
VitessYouTube、Slack、GitHub视频、协作、代码托管
CitusMicrosoft、Heap、MixRank云服务、分析、营销
行业应用分布
35%25%15%12%8%5%分库分表框架行业应用分布电商零售金融支付社交媒体企业服务游戏娱乐其他

4. 技术选型指南

4.1 选型决策树

千万级
亿级
十亿级+
较强
一般
选择分库分表方案
数据量级别?
ShardingSphere
功能全面，易上手
团队技术水平?
Vitess
超大规模专用
ShardingSphere
或 自研方案
Mycat
简单稳定
适合：
• 中小型互联网公司
• 快速迭代项目
• 需要完整生态
适合：
• 传统企业
• 稳定性优先
• 简单分片需求
适合：
• 大型互联网公司
• 复杂业务场景
• 有技术团队
适合：
• 超大规模应用
• 云原生架构
• 全球化部署

4.2 具体场景推荐

🏢 企业级应用
/*** 企业级分库分表选型*/
public class EnterpriseScenario {// 传统企业 - 稳定优先public void traditionalEnterprise() {/** 推荐：Mycat* * 理由：* • 部署运维简单* • 性能稳定可靠* • 对现有系统改动小* • 技术门槛低*/}// 互联网公司 - 功能优先public void internetCompany() {/** 推荐：ShardingSphere* * 理由：* • 功能丰富完善* • 生态系统成熟* • 社区支持好* • 持续更新迭代*/}// 大型互联网 - 性能优先public void largeScaleInternet() {/** 推荐：Vitess 或 自研* * 理由：* • 超大规模数据支持* • 云原生架构* • 自动化运维* • 可定制性强*/}
}

5. 实战案例对比

5.1 电商系统分库分表

/*** 电商系统分库分表实战*/
public class ECommerceSharding {// 用户表分片策略public void userTableSharding() {/** 分片键：user_id* 分片算法：hash取模* 分库：4个库* 分表：每库4张表* * 路由规则：* 库：user_id % 4* 表：user_id % 16 / 4*/}// 订单表分片策略public void orderTableSharding() {/** 分片键：user_id (保证用户订单在同一库)* 分片算法：hash取模* 时间维度：按月分表* * 路由规则：* 库：user_id % 4* 表：order_202401, order_202402...*/}
}

5.2 金融系统分库分表

/*** 金融系统分库分表实战*/
public class FinancialSharding {// 账户表分片策略public void accountTableSharding() {/** 分片键：account_id* 分片算法：range分片* 分库：按账户号段* * 路由规则：* 1-100万：db1* 100-200万：db2* 200-300万：db3*/}// 交易流水表分片策略public void transactionTableSharding() {/** 分片键：account_id + 时间* 分片算法：复合分片* * 路由规则：* 先按account_id确定库* 再按时间确定表*/}
}

6. 数据同步与读写分离方案

6.1 数据同步框架对比

6.1.1 Canal (阿里巴巴)
/*** Canal数据同步示例*/
public class CanalDataSync {public void startCanalClient() {// 创建链接CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress("127.0.0.1", 11111), "example", "", "");try {connector.connect();connector.subscribe(".*\\..*");connector.rollback();while (true) {Message message = connector.getWithoutAck(1000);long batchId = message.getId();if (batchId != -1 && !message.getEntries().isEmpty()) {processEntries(message.getEntries());}connector.ack(batchId);}} finally {connector.disconnect();}}
}
6.1.2 Maxwell (Zendesk)
{"database": "test","table": "users","type": "insert","ts": 1449786310,"xid": 23396,"data": {"id": 1,"name": "张三","email": "zhangsan@example.com"}
}
6.1.3 Debezium (Red Hat)
# Debezium MySQL连接器配置
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:name: debezium-connect
spec:replicas: 1bootstrapServers: kafka-cluster:9092config:group.id: debezium-clusteroffset.storage.topic: debezium-cluster-offsetsconfig.storage.topic: debezium-cluster-configsstatus.storage.topic: debezium-cluster-status
数据同步框架对比
框架开发公司特点适用场景优势劣势
Canal阿里巴巴基于MySQL binlog实时同步性能高、稳定仅支持MySQL
MaxwellZendeskJSON格式输出数据分析简单易用功能相对简单
DebeziumRed Hat基于Kafka Connect微服务架构生态丰富复杂度较高
DataX阿里巴巴离线批量同步数据迁移支持多数据源非实时
SqoopApacheHadoop生态大数据场景与Hadoop集成好学习成本高

6.2 读写分离实现方案

6.2.1 应用层读写分离
/*** 应用层读写分离实现*/
@Service
public class UserService {@Autowired@Qualifier("masterDataSource")private DataSource masterDataSource;@Autowired@Qualifier("slaveDataSource") private DataSource slaveDataSource;// 写操作使用主库@Transactionalpublic void createUser(User user) {// 自动路由到主库userMapper.insert(user);}// 读操作使用从库@Transactional(readOnly = true)public User getUserById(Long id) {// 自动路由到从库return userMapper.selectById(id);}
}
6.2.2 中间件读写分离
# ShardingSphere读写分离配置
spring:shardingsphere:datasource:names: master,slave0,slave1master:type: com.zaxxer.hikari.HikariDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://localhost:3306/master_dbslave0:type: com.zaxxer.hikari.HikariDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://localhost:3307/slave_db0rules:readwrite-splitting:data-sources:readwrite_ds:write-data-source-name: masterread-data-source-names: slave0,slave1load-balancer-name: round_robinload-balancers:round_robin:type: ROUND_ROBIN
读写分离方案对比
实现方式优势劣势适用场景
应用层控制精确、性能好代码侵入性强简单业务
中间件透明化、功能丰富增加复杂度复杂业务
数据库代理完全透明单点故障风险遗留系统

7. 最佳实践与避坑指南

7.1 分片键选择原则

/*** 分片键选择最佳实践*/
public class ShardingKeyBestPractices {// ✅ 好的分片键特征public void goodShardingKey() {/** 1. 数据分布均匀* 2. 查询覆盖率高* 3. 业务相关性强* 4. 更新频率低* 5. 数据类型简单*/}// ❌ 避免的分片键public void badShardingKey() {/** 1. 时间字段（数据倾斜）* 2. 状态字段（分布不均）* 3. 自增ID（热点问题）* 4. 业务无关字段* 5. 复杂计算字段*/}
}

7.2 常见问题与解决方案

跨库查询问题
/*** 跨库查询解决方案*/
public class CrossShardQuery {// 方案1：应用层聚合public List<Order> queryOrdersByUserId(Long userId) {// 确定分片List<String> shards = getShardsByUserId(userId);// 并行查询List<CompletableFuture<List<Order>>> futures = shards.stream().map(shard -> CompletableFuture.supplyAsync(() -> queryOrdersFromShard(shard, userId))).collect(Collectors.toList());// 结果聚合return futures.stream().map(CompletableFuture::join).flatMap(List::stream).collect(Collectors.toList());}// 方案2：数据冗余public void dataRedundancy() {/** 在需要跨库查询的场景下* 适当冗余数据到统一的查询库* * 优点：查询简单* 缺点：数据一致性复杂*/}
}

8. 面试要点总结

Q1: 什么情况下需要分库分表？

答案：

  1. 单表数据量过大：超过1000万条记录
  2. 查询性能下降：索引效果不明显
  3. 并发压力大：单库连接数不够
  4. 存储空间限制：单库容量达到瓶颈
  5. 业务增长快速：预期数据量快速增长

Q2: 分库分表有哪些策略？

答案：

  • 垂直分库：按业务模块拆分
  • 垂直分表：按字段拆分冷热数据
  • 水平分库：按数据特征分散到多个库
  • 水平分表：按数据量拆分到多张表

Q3: 如何选择分片键？

答案：

  1. 数据分布均匀：避免数据倾斜
  2. 查询覆盖率高：大部分查询都包含分片键
  3. 业务相关性强：与核心业务逻辑相关
  4. 更新频率低：避免频繁修改分片键
  5. 类型简单：整型或字符串类型

Q4: 分库分表后如何处理跨库查询？

答案：

  1. 应用层聚合：查询多个分片后在应用层合并
  2. 数据冗余：将需要跨库查询的数据冗余存储
  3. 中间表：创建专门的汇总表
  4. 搜索引擎：使用ES等搜索引擎
  5. 大数据组件：使用Spark、Flink等处理

Q5: ShardingSphere和Mycat的区别？

答案：

对比项ShardingSphereMycat
架构应用层框架数据库代理
功能功能丰富全面专注分库分表
性能中等较高
维护活跃缓慢
学习成本中等较低

记忆口诀

分库分表选框架，场景需求要分析；
ShardingSphere功能全，生态完善易上手；
Mycat简单性能好，中小企业首选择；
Vitess云原生架构，超大规模显威力；
数据同步有Canal，实时binlog是利器；
读写分离提性能，主从架构要配齐；
分片键选择要谨慎，数据均匀是关键；
跨库查询需优化，冗余聚合两手抓。

总结

架构师老王：选择分库分表方案需要综合考虑：

  1. 数据规模：千万级、亿级、十亿级对应不同方案
  2. 团队能力：技术水平决定了方案的复杂度
  3. 业务场景：OLTP、OLAP、混合场景有不同要求
  4. 运维成本：考虑长期的维护和扩展成本

ShardingSphere师傅：功能全面，适合大多数场景！

Mycat大师：简单稳定，传统企业的好选择！

Vitess长老：云原生时代，我是未来趋势！

记住：没有最好的方案，只有最适合的方案！

分库分表，让数据库性能飞起来！ 🚀

📌 行动指南

  1. 点赞 → 让更多Java开发者掌握数据库技术
  2. 评论 → 留言"数据库技术"领取[MySQL性能优化指南]
  3. 关注 → 追踪更新《分布式事务解决方案》（已写完待发布）
  4. 赞赏 → 解锁完整源码+专属技术咨询

🚀 下期预告
《分布式事务解决方案》关注可抢先看

📚 相关推荐：

  • 漫画Java基础
  • 漫画Spring全家桶
  • 漫画JVM调优

让我们一起在Java的世界里探索更多精彩内容！ 🚀

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/diannao/90814.shtml
繁体地址，请注明出处：http://hk.pswp.cn/diannao/90814.shtml
英文地址，请注明出处：http://en.pswp.cn/diannao/90814.shtml

如若内容造成侵权/违法违规/事实不符，请联系英文站点网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Tomcat问题：启动脚本startup.bat中文乱码问题解决

Tomcat问题：启动脚本startup.bat中文乱码问题解决

一、问题描述 我们第一次下载或者打开Tomcat时可能在控制台会出现中文乱码问题二、解决办法 我的是8.x版本的tomcat用notepad打开&#xff1a;logging.properties 找到&#xff1a;java.util.logging.ConsoleHandler.encoding设置成GBK&#xff0c;重启tomcat即可
阅读更多...
Linux中Gitee的使用

Linux中Gitee的使用

一、Gitee简介&#xff1a;Gitee&#xff08;码云&#xff09;是中国的一个代码托管和协作开发平台&#xff0c;类似于GitHub或GitLab&#xff0c;主要面向开发者提供代码管理、项目协作及开源生态服务。适用场景个人开发者&#xff1a;托管私有代码或参与开源项目。中小企业&a…
阅读更多...
Oracle大表数据清理优化与注意事项详解

Oracle大表数据清理优化与注意事项详解

一、性能优化策略 1. 批量处理优化批量大小选择&#xff1a; 小批量(1,000-10,000行)&#xff1a;减少UNDO生成&#xff0c;但需要更多提交次数中批量(10,000-100,000行)&#xff1a;平衡性能与资源消耗大批量(100,000行)&#xff1a;适合高配置环境&#xff0c;但需监控资源使…
阅读更多...
Anaconda及Conda介绍及使用

Anaconda及Conda介绍及使用

文章目录Anaconda简介为什么选择 Anaconda&#xff1f;Anaconda 安装Win 平台macOS 平台Linux 平台Anaconda 界面使用Conda简介Conda下载安装conda 命令环境管理包管理其他常用命令Jupyter Notebook&#xff08;可选&#xff09;Anaconda简介 Anaconda 是一个数据科学和机器学…
阅读更多...
外包干了一周，技术明显退步

外包干了一周，技术明显退步

我是一名本科生&#xff0c;自2019年起&#xff0c;我便在南京某软件公司担任功能测试的工作。这份工作虽然稳定&#xff0c;但日复一日的重复性工作让我逐渐陷入了舒适区&#xff0c;失去了前进的动力。两年的时光匆匆流逝&#xff0c;我却在原地踏步&#xff0c;技术没有丝毫…
阅读更多...
【QT】多线程相关教程

【QT】多线程相关教程

一、核心概念与 Qt 线程模型 1.线程与进程的区别: 线程是程序执行的最小单元&#xff0c;进程是资源分配的最小单元&#xff0c;线程共享进程的内存空间(堆&#xff0c;全局变量等)&#xff0c;而进程拥有独立的内存空间。Qt线程只要关注同一进程内的并发。 2.为什么使用多线程…
阅读更多...
VS 版本更新git安全保护问题的解决

VS 版本更新git安全保护问题的解决

问题&#xff1a;我可能移动了一个VS C# 项目&#xff0c;然后&#xff0c;发现里面的git版本检测不能用了 正在打开存储库: X:\Prj_C#\3D fatal: detected dubious ownership in repository at X:/Prj_C#/3DSnapCatch X:/Prj_C#/3D is owned by:S-1-5-32-544 but the current …
阅读更多...
Git常用命令一览

Git常用命令一览

Git 是基于 Linux内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同&#xff0c;它采用了分布式版本库的方式&#xff0c;不必服务器端软件支持&#xff08;ps&#xff1a;这得分是用什么样的服务端&#xff0c;使用http协议或者git协议等不太一样。并且在…
阅读更多...
基于 JSON 文件定位图片缺陷点并保存

基于 JSON 文件定位图片缺陷点并保存

基于JSON的图片缺陷处理流程 ├── 1. 输入检查 │ ├── 验证图片文件是否存在 │ └── 验证JSON文件是否存在 │ ├── 2. 数据加载 │ ├── 打开并加载图片 │ └── 读取并解析JSON文件 │ ├── 3. 缺陷信息提取 │ ├── 检查JSON中是否存在shapes字…
阅读更多...
Redis基础学习（五大值数据类型的常用操作命令）

Redis基础学习（五大值数据类型的常用操作命令）

目录 一、Redis基本知识与Redis键&#xff08;key&#xff09;常用操作命令。 二、Redis的五大值的数据类型。&#xff08;value&#xff09; 三、Redis关于键&#xff08;key&#xff09;的值常用操作指令表格统计。 &#xff08;1&#xff09;字符串&#xff08;String&#…
阅读更多...
Ubuntu——办公软件 LibreOffice 安装与使用指南

Ubuntu——办公软件 LibreOffice 安装与使用指南

十四、LibreOffice 安装与使用1、核心组件组件​​​​图标​​​​对应MS Office​​​​核心功能定位​​​​Writer​​&#x1f4dd;Word专业文档处理与排版​​Calc​​&#x1f4ca;Excel数据计算与分析​​Impress​​&#x1f3ac;PowerPoint演示文稿制作​​Draw​​&…
阅读更多...
Securecrt丢失tab以及终端重新配色

Securecrt丢失tab以及终端重新配色

今天在使用 Securecrt 的时候&#xff0c;发现 Securecrt 的 tab 标签消失不见了&#xff0c;仔细回想起来&#xff0c;应该是上一次误按了 alt enter 最大化&#xff0c;然后导致配置丢失的问题 还有表现就是菜单中的 Session Tabs 无论勾选还是不勾选都没有任何变化&#xf…
阅读更多...
frp搭建内网穿透教程

frp搭建内网穿透教程

frp搭建内网穿透教程 步骤1&#xff1a;准备工作 公网服务器&#xff1a;需要一台具有公网IP的服务器作为中转服务器&#xff0c;安装frp服务器端&#xff08;frps&#xff09;。内网设备&#xff1a;需要暴露服务的内网设备&#xff0c;安装frp客户端&#xff08;frpc&#xf…
阅读更多...
【JavaEE进阶】图书管理系统（未完待续）

【JavaEE进阶】图书管理系统（未完待续）

目录 用户登录 添加图书 图书列表 修改图书 删除图书 批量删除 拦截器 &#x1f343;前言 什么是拦截器? 拦截器的基本使用 自定义拦截器 注册配置拦截器 拦截路径 拦截器执行流程 项目实现统一拦截 定义拦截器 注册配置拦截器 前⾯图书管理系统, 咱们只完成了⽤⼾登录和图书列…
阅读更多...
基于同花顺API的熊市与牛市识别模型开发及因子分析

基于同花顺API的熊市与牛市识别模型开发及因子分析

基于同花顺API的熊市与牛市识别模型开发及因子分析 1. 引言 1.1 研究背景与意义 金融市场中的牛市与熊市识别一直是投资者和研究人员关注的重点问题。牛市(Bull Market)通常指价格持续上涨的市场环境，投资者信心充足，交易活跃；而熊市(Bear Market)则指价格持续下跌的市场…
阅读更多...
AMD 锐龙 AI MAX+ 395 处理器与端侧 AI 部署的行业实践

AMD 锐龙 AI MAX+ 395 处理器与端侧 AI 部署的行业实践

2025 年 7 月 10 日&#xff0c;AMD 在深圳召开 Mini AI 工作站行业解决方案峰会&#xff0c;正式发布基于锐龙 AI MAX 395 处理器的端侧 AI 部署方案&#xff0c;与 200 余家生态伙伴共同探讨 AI 技术在千行百业的落地路径。这一硬件平台通过异构计算架构与开放生态设计&#…
阅读更多...
期权盘位是什么意思？

期权盘位是什么意思？

本文主要介绍期权盘位是什么意思&#xff1f;“期权盘位”并非金融交易中的标准术语&#xff0c;可能是口语化表达或对某些概念的简化描述。期权盘位是什么意思&#xff1f;1. 期权盘口的“价位”&#xff08;买卖报价位置&#xff09;在期权交易中&#xff0c;“盘口”通常指实…
阅读更多...
【Trea】Trea国内版｜国际版｜海外版下载｜Mac版｜Windows版|Linux下载配置教程

【Trea】Trea国内版｜国际版｜海外版下载｜Mac版｜Windows版|Linux下载配置教程

【Trea】Trea国内版&#xff5c;国际版&#xff5c;海外版下载&#xff5c;Mac版&#xff5c;Windows版下载配置教程 本文适用读者&#xff1a; 想要第一次安装 Trea需要在 Windows 或 macOS 上完成环境配置想深入了解 Doubao、DeepSeek、ChatGPT、Claude 等模型在 Trea 中的接…
阅读更多...
MyBatis实现分页查询-苍穹外卖笔记

MyBatis实现分页查询-苍穹外卖笔记

首先分页查询的原理是SQL的limit关键字。LIMIT 子句用于限制 SQL 查询返回的记录数。它接受一个或两个整数参数&#xff0c;第一个参数表示偏移量&#xff0c;第二个参数表示返回的最大记录数。我们完全可以使用前端传给我们的page,pageSize,自己去计算limit的参数&#xff0c;…
阅读更多...
系统性能评估方法深度解析：从经典到现代

系统性能评估方法深度解析：从经典到现代

评估本质&#xff1a;系统性能评估是通过量化分析衡量计算机系统在特定工作负载下的表现能力&#xff0c;核心目标是建立可比较的性能基准&#xff0c;为系统设计、选型和优化提供科学依据。一、评估方法分类体系 #mermaid-svg-0ceD4AA2KDwzwtb6 {font-family:"trebuchet …
阅读更多...
最新文章

Copyright @ 2022~2023