TiDB 和 MySQL的差异_戴国进的博客-CSDN博客_tidb与mysql
TiDB 和 MySQL的差异
戴国进
于 2020-10-06 23:04:43 发布
13286
收藏
16
分类专栏：
mysql | tidb
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/JineD/article/details/108945022
版权
mysql | tidb
专栏收录该内容
34 篇文章
3 订阅
订阅专栏
世界级的开源分布式数据库 TiDB 自 2016 年 12 月正式发布第一个版本以来，业内诸多公司逐步引入使用，并取得广泛认可。  对于互联网公司，数据存储的重要性不言而喻。在 NewSQL 数据库出现之前，一般采用单机数据库（比如 MySQL）作为存储，随着数据量的增加，“分库分表”是早晚面临的问题，即使有诸如 MyCat、ShardingJDBC 等优秀的中间件，“分库分表”还是给 RD 和 DBA 带来较高的成本；NewSQL 数据库出现后，由于它不仅有 NoSQL 对海量数据的管理存储能力、还支持传统关系数据库的 ACID 和 SQL，所以对业务开发来说，存储问题已经变得更加简单友好，进而可以更专注于业务本身。而 TiDB，正是 NewSQL 的一个杰出代表！  站在业务开发的视角，TiDB 最吸引人的几大特性是： 
支持 MySQL 协议（开发接入成本低）； 100% 支持事务（数据一致性实现简单、可靠）； 无限水平拓展（不必考虑分库分表）。   
基于这几大特性，TiDB 在业务开发中是值得推广和实践的，但是，它毕竟不是传统的关系型数据库，以致我们对关系型数据库的一些使用经验和积累，在 TiDB 中是存在差异的，现主要阐述“事务”和“查询”两方面的差异。
TiDB 事务和 MySQL 事务的差异MySQL 事务和 TiDB 事务对比
在 TiDB 中执行的事务 b，返回影响条数是 1（认为已经修改成功），但是提交后查询，status 却不是事务 b 修改的值，而是事务 a 修改的值。 可见，MySQL 事务和 TiDB 事务存在这样的差异：MySQL 事务中，可以通过影响条数，作为写入（或修改）是否成功的依据；而在 TiDB 中，这却是不可行的！ 作为开发者我们需要考虑下面的问题： 同步 RPC 调用中，如果需要严格依赖影响条数以确认返回值，那将如何是好？ 多表操作中，如果需要严格依赖某个主表数据更新结果，作为是否更新（或写入）其他表的判断依据，那又将如何是好？ 原因分析及解决方案
对于 MySQL，当更新某条记录时，会先获取该记录对应的行级锁（排他锁），获取成功则进行后续的事务操作，获取失败则阻塞等待。对于 TiDB，使用 Percolator 事务模型：可以理解为乐观锁实现，事务开启、事务中都不会加锁，而是在提交时才加锁。参见 这篇文章（TiDB 事务算法）。
其简要流程如下：
在事务提交的 PreWrite 阶段，当“锁检查”失败时：如果开启冲突重试，事务提交将会进行重试；如果未开启冲突重试，将会抛出写入冲突异常。 可见，对于 MySQL，由于在写入操作时加上了排他锁，变相将并行事务从逻辑上串行化；而对于 TiDB，属于乐观锁模型，在事务提交时才加锁，并使用事务开启时获取的“全局时间戳”作为“锁检查”的依据。 所以，在业务层面避免 TiDB 事务差异的本质在于避免锁冲突，即，当前事务执行时，不产生别的事务时间戳（无其他事务并行）。处理方式为事务串行化。 TiDB 事务串行化 在业务层，可以借助分布式锁，实现串行化处理，如下：
基于 Spring 和分布式锁的事务管理器拓展 在 Spring 生态下，spring-tx 中定义了统一的事务管理器接口：PlatformTransactionManager，其中有获取事务（getTransaction）、提交（commit）、回滚（rollback）三个基本方法；使用装饰器模式，事务串行化组件可做如下设计：
其中，关键点有： 超时时间：为避免死锁，锁必须有超时时间；为避免锁超时导致事务并行，事务必须有超时时间，而且锁超时时间必须大于事务超时时间（时间差最好在秒级）。 加锁时机：TiDB 中“锁检查”的依据是事务开启时获取的“全局时间戳”，所以加锁时机必须在事务开启前。 事务模板接口设计 隐藏复杂的事务重写逻辑，暴露简单友好的 API：
TiDB 查询和 MySQL 的差异 在 TiDB 使用过程中，偶尔会有这样的情况，某几个字段建立了索引，但是查询过程还是很慢，甚至不经过索引检索。索引混淆型（举例） 表结构：
1 2 3 4 5 6 7 8 9 CREATE TABLE `t_test` (       `id` bigint(20) NOT NULL DEFAULT '0' COMMENT '主键id',       `a` int(11) NOT NULL DEFAULT '0' COMMENT 'a',       `b` int(11) NOT NULL DEFAULT '0' COMMENT 'b',       `c` int(11) NOT NULL DEFAULT '0' COMMENT 'c',       PRIMARY KEY (`id`),       KEY `idx_a_b` (`a`,`b`),       KEY `idx_c` (`c`)     ) ENGINE=InnoDB;
查询：如果需要查询 (a=1 且 b=1）或 c=2 的数据，在 MySQL 中，sql 可以写为：SELECT id from t_test where (a=1 and b=1) or (c=2);，MySQL 做查询优化时，会检索到 idx_a_b 和 idx_c 两个索引；但是在 TiDB（v2.0.8-9）中，这个 sql 会成为一个慢 SQL，需要改写为：
1 SELECT id from t_test where (a=1 and b=1) UNION SELECT id from t_test where (c=2);
小结：导致该问题的原因，可以理解为 TiDB 的 sql 解析还有优化空间。冷热数据型（举例） 表结构：
1 2 3 4 5 6 7 8 9 10 CREATE TABLE `t_job_record` (       `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键id',       `job_code` varchar(255) NOT NULL DEFAULT '' COMMENT '任务code',       `record_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '记录id',       `status` tinyint(3) NOT NULL DEFAULT '0' COMMENT '执行状态:0 待处理',       `execute_time` bigint(20) NOT NULL DEFAULT '0' COMMENT '执行时间（毫秒）',       PRIMARY KEY (`id`),       KEY `idx_status_execute_time` (`status`,`execute_time`),       KEY `idx_record_id` (`record_id`)     ) ENGINE=InnoDB COMMENT='异步任务job'
数据说明： a. 冷数据，status=1 的数据（已经处理过的数据）； b. 热数据，status=0 并且 execute_time<= 当前时间 的数据。 慢查询：对于热数据，数据量一般不大，但是查询频度很高，假设当前（毫秒级）时间为：1546361579646，则在 MySQL 中，查询 sql 为：
1 SELECT * FROM t_job_record where status=0 and execute_time<= 1546361579646
这个在 MySQL 中很高效的查询，在 TiDB 中虽然也可从索引检索，但其耗时却不尽人意（百万级数据量，耗时百毫秒级）。 原因分析：在 TiDB 中，底层索引结构为 LSM-Tree，如下图：
当从内存级的 C0 层查询不到数据时，会逐层扫描硬盘中各层；且 merge 操作为异步操作，索引数据更新会存在一定的延迟，可能存在无效索引。由于逐层扫描和异步 merge，使得查询效率较低。 优化方式：尽可能缩小过滤范围，比如结合异步 job 获取记录频率，在保证不遗漏数据的前提下，合理设置 execute_time 筛选区间，例如 1 小时，sql 改写为：
1 SELECT * FROM t_job_record  where status=0 and execute_time>1546357979646  and execute_time<= 1546361579646
优化效果：耗时 10 毫秒级别（以下）。 关于查询的启发 在基于 TiDB 的业务开发中，先摒弃传统关系型数据库带来的对 sql 先入为主的理解或经验，谨慎设计每一个 sql，如 DBA 所提倡：设计 sql 时务必关注执行计划，必要时请教 DBA。 和 MySQL 相比，TiDB 的底层存储和结构决定了其特殊性和差异性；但是，TiDB 支持 MySQL 协议，它们也存在一些共同之处，比如在 TiDB 中使用“预编译”和“批处理”，同样可以获得一定的性能提升。 服务端预编译 在 MySQL 中，可以使用 PREPARE stmt_name FROM preparable_stm 对 sql 语句进行预编译，然后使用 EXECUTE stmt_name [USING @var_name [, @var_name] ...] 执行预编译语句。如此，同一 sql 的多次操作，可以获得比常规 sql 更高的性能。 mysql-jdbc 源码中，实现了标准的 Statement 和 PreparedStatement 的同时，还有一个ServerPreparedStatement 实现，ServerPreparedStatement 属于PreparedStatement的拓展，三者对比如下：
容易发现，PreparedStatement 和 Statement 的区别主要区别在于参数处理，而对于发送数据包，调用服务端的处理逻辑是一样（或类似）的；经测试，二者速度相当。其实，PreparedStatement 并不是服务端预处理的；ServerPreparedStatement 才是真正的服务端预处理，速度也较 PreparedStatement 快；其使用场景一般是：频繁的数据库访问，sql 数量有限（有缓存淘汰策略，使用不宜会导致两次 IO）。 批处理 对于多条数据写入，常用 sql 为 insert … values (…),(…)；而对于多条数据更新，亦可以使用 update … case … when… then… end 来减少 IO 次数。但它们都有一个特点，数据条数越多，sql 越加复杂，sql 解析成本也更高，耗时增长可能高于线性增长。而批处理，可以复用一条简单 sql，实现批量数据的写入或更新，为系统带来更低、更稳定的耗时。 对于批处理，作为客户端，java.sql.Statement 主要定义了两个接口方法，addBatch 和 executeBatch 来支持批处理。 批处理的简要流程说明如下：
经业务中实践，使用批处理方式的写入（或更新），比常规 insert … values(…),(…)（或 update … case … when… then… end）性能更稳定，耗时也更低。
戴国进
关注
关注
点赞
16
收藏
打赏
评论
TiDB 和 MySQL的差异
世界级的开源分布式数据库 TiDB 自 2016 年 12 月正式发布第一个版本以来，业内诸多公司逐步引入使用，并取得广泛认可。对于互联网公司，数据存储的重要性不言而喻。在 NewSQL 数据库出现之前，一般采用单机数据库（比如 MySQL）作为存储，随着数据量的增加，“分库分表”是早晚面临的问题，即使有诸如 MyCat、ShardingJDBC 等优秀的中间件，“分库分表”还是给 RD 和 DBA 带来较高的成本；NewSQL 数据库出现后，由于它不仅有 NoSQL 对海量数据的管理存储能力、还支持传.
复制链接
扫一扫
专栏目录
TIDB和MySQL性能对比
justlpf的专栏
07-21
3804
对比TiDB和MySQL在大表复杂join方面，TiDB比MySQL快很多（至少三倍），这应该得益于TiDB的 分布式架构，把逻辑计算下推到各个数据节点并行执行导致的。
由于TiDB有着很好的水平分布式扩展，突破了单实例容量的限制，和分库分表比，应该有着更好的优势。
TiDB会降低开发和运维的复杂度，在2020到来之前，我继续调研这个数据库。
目前计划先把tidb作为MySQL从库使用，架构如下：
...
MySQL与TiDB基础知识类比
wanghao112956的博客
08-20
424
温故而知新 可以为师矣
（想自学习编程的小伙伴请搜索圈T社区，更多行业相关资讯更有行业相关免费视频教程。完全免费哦!）
一、存储模型
MySQL
Each tablespace consists of database pages with a default size of 16KB. The pages are grouped into extents of size 1MB (64 co...
评论 2
您还未登录，请先
登录
后发表或查看评论
tidb：TiDB是与MySQL协议兼容的开源分布式HTAP数据库
02-03
推特：
邮件列表： 网上
什么是TiDB？
TiDB（“ Ti”代表Titanium）是一个开源的NewSQL数据库，它支持混合事务处理和分析处理（HTAP）工作负载。 它与MySQL兼容，并具有水平可伸缩性，强一致性和高可用性。
水平可伸缩性
TiDB只需添加新节点即可扩展SQL处理和存储。 与仅纵向扩展的传统关系数据库相比，这使基础架构容量规划既简单又更具成本效益。
MySQL兼容语法
TiDB就像它是应用程序MySQL 5.7服务器一样。 您可以继续使用所有现有MySQL客户端库，并且在许多情况下，您无需在应用程序中更改任何代码行。 由于TiDB是从头开始构建的，而不是MySQL
分布式数据库TiDB介绍
最新发布
oceanbase,xml上传漏洞
11-12
420
TiDB 是一款定位于在线事务处理 / 在线分析处理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 OLAP 等重要特性。同时兼容 MySQL 协议和生态，迁移便捷，运维成本低。一、TiDB介绍
与传统的单机数据库相比，TiDB具有以下优势：
纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容支持SQL，对外暴露MySQL的网络协议，并兼容大多数MySQL的语法，在
TiDB-新一代数据库入门介绍
十步杀一人-千里不留行
11-13
9688
由于目前的项目计划把MySQL换成TiDB，所以特意来了解下TiDB。其实也不能说换，由于TiDB和MySQL几乎完全兼容，所以我们的程序可以没有任何改动就完成数据库从MySQL到TiDB的转换。接下来了解一下TiDB，为将来的技术选型做个准备。
一、TiDB介绍
TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid...
TiDB适用和不适用场景
热门推荐
“IT-老兵” 的博客
07-06
4万+
TiDB 的典型的应用场景是：(1) 原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时，可以考虑使用 TiDB 无缝替换 MySQL。TiDB 可以提供如下特性：吞吐量、存储和计算能力的水平扩展水平伸缩时不停服务强一致性分布式 ACID 事务(2) 大数据量下，MySQL 复杂查询很慢。(3) 大数据量下，数据增长很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、...
TIDB入门了解，对比MySql
Itissohardtog的博客
11-23
4465
TIDB是什么？MySql是什么？
TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是...
TIDB和mysql优缺点对比
zjy_love_java的博客
08-06
1万+
最近这几年，公司一直在使用mysql，数据量在千万级以下时，mysql有着非常优秀的性能和稳定性。随着数据增长，单表无法满足业务需求，我们需要使用mycat、shading-jdbc等中间件去实现分库分表。
分库分表的缺点：
分页查询性能不好，需求聚合多库数据，多次io，内存消耗大。
分布式事务问题
分库之后，想二次扩容，数据迁移等会更复杂
跨库join很难实现
随着newsql数据库出现，分库分表这些问题都得到解决，
newsql特性如下：
SQL支持 （TiDB 是 MySQL 兼容的）
水平线性
tidb使用坑记录&TiDB和Mysql的sql差异总结
荒野求生的博客
08-11
8138
tidb使用坑记录
1、对硬盘要求很高，没上SSD硬盘的不建议使用
2、不支持分区，删除数据是个大坑。
解决方案：set @@session.tidb_batch_delete=1;
3、插入数据太大也会报错
解决方案：set @@session.tidb_batch_insert=1;
4、删除表数据时不支持别名
delete from 表名 表别名where表别名.col = '1' 会报错
5、内存使用有问题，GO语言导致不知道回收机制什么时候运作。内存使用过多会导致T...
TIDB数据库特性总结
qq_43403676的博客
05-22
2235
TIDB是一个开源分布式关系型数据库，是NewSQL的一个代表。TIDB具有很多优秀的特性，例如：实现一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时OLAP等重要特性。一言以蔽之：TIDB未来可期。
TiDB 性能分析&性能调优&优化实践大全
TiDBer的博客
06-20
945
本文介绍了基于数据库时间的系统优化方法，以及如何利用 TiDB Performance Overview 面板 8进行性能分析和优化。通过本文中介绍的方法，你可以从全局、自顶向下的角度分析用户响应时间和数据库时间，确认用户响应时间的瓶颈是否在数据库中。如果瓶颈在数据库中，你可以通过数据库时间概览和 SQL 延迟的分解，定位数据库内部的瓶颈点，并进行针对性的优化。TiDB 对 SQL 的处理路径和数据库时间进行了完善的测量和记录，方便定位数...
tidb mysql兼容_兼容性 - 与 MySQL 的兼容性 - 《TiDB v4.0 用户文档》 - 书栈网 · BookStack...
weixin_39541767的博客
01-27
391
与 MySQL 兼容性对比概览TiDB 100% 兼容 MySQL5.7 协议、MySQL5.7 常用的功能及语法，MySQL5.7 生态中系统的工具(PHPMyAdmin, Navicat, MySQL Workbench、mysqldump、Mydumper/myloader)、客户端等均用于 TiDB。TiDB 是一款分布式数据库， MySQL5.7 中的部分特性由于工程实现难较大，投入产出...
TiDB与Mysql相关
阿正的博客
03-05
878
https://www.v2ex.com/t/508094美团点评 TiDB 深度实践之旅（9000 字长文 / 真实“踩坑”经历）
https://segmentfault.com/a/1190000008644583日均数据量千万级，MySQL、TiDB 两种存储方案的落地对比
https://blog.csdn.net/D_Guco/article/details/80641236...
遇见 TiDB，放弃MySQL
魂影魔宅
12-22
1万+
最近TiDB掀起了一波分布式数据库的热潮，公司也在着手准备TiDB的落地工作，前几天也参与了几场公司针对TiDB的分享会，下面我们了解一下关于TiDB。
TiDB 是什么？
TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库...
Tidb索引数据结构（LSM-TREE）
weixin_33725270的博客
03-28
4456
2019独角兽企业重金招聘Python工程师标准>>>
...
MongoDB和TiDB
qq_46185277的博客
03-11
1689
对MongoDB和TiDB的系统比较
一、MongoDB
1、简介
MongoDB 是一个基于分布式文件存储的文档数据库，属于NoSQL数据库，是非关系数据库当中功能最丰富，最像关系数据库的。支持多种查询语言，支持对数据建立任何属性的索引，使用高效的二进制数据存储，自动处理碎片，高性能、易部署、易使用，存储数据非常方便。
2、设计与使用原理
“面向集合”和“模式自由”：
数据分组被储存在数据集中，称为而一个集合，每个集合都有一个唯一的标识名，并且可以包含无数数目的文档，集合类似于数据库的表，但不需要定义任何
分布式数据库-TiDB应用场景简介
MayMatrix 的博客
02-27
1524
前言：最近公司要讨论分库分表，正好一起参加了培训。一般mysql单表数据库容量达到一定的极限，性能会急剧下降，之前工作的时候已经大佬们高喊几次了分库分表，但是最终没能实现或者落地的方案不佳。在这里一篇很好的文章指出了当前开源的分库分表的框架的不足，并介绍了使用TiDb作为新的分布式数据库的各种优点传送门。
目前的常用的分库分表概述
一种是中间件代理，例如mycat和sharding-proxy...
猿创征文｜一文带你了解国产TiDB数据库
一个菜鸡的博客
10-04
889
很多小伙伴在日常接触中接触国产数据库很少，大部分在开发应用上使用的是由甲骨文，微软等公司提供了MySQL，SQLserver。普通程序员很少能用到newSQl数据库，TiDB就是一种newSQL数据库，在大趋势下，向国际对接是避免不了的，但也存在一个问题，近期看到新闻国外某知名数据库厂商宣布称“暂停在俄罗斯的所有业务”，相信很多国内小伙伴的心情，绝不是隔岸观火，而是细思恐极。数据库产品一直都是国内人员的焦点话题，面对现如今全球的“非常时期”，国产数据库到底能不能支棱起来呢？今天呢我就带领大家认识国产数据库T
TiDB的调研
yang52017的博客
04-15
4259
文章目录TiDB的调研TiDB的特性能够解决什么问题与mysql的兼容性对比TID的架构TiDB 的整体架构SQL on KV 架构SQL 层架构几个重要的概念业界的应用场景头条为什么使用场景TIDB的缺点
TiDB的调研
TiDB的特性
高度兼容 MySQL
大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：代码科技
设计师：Amelia_0503
返回首页
戴国进
CSDN认证博客专家
CSDN认证企业博客
码龄12年
深圳万兴科技
512
原创
936
周排名
406
总排名
448万+
访问
等级
2万+
积分
1万+
粉丝
487
获赞
154
评论
1906
收藏
私信
关注
热门文章
完美解决 Could not find a version that satisfies the requirement 安装包名字 (from versions: )
113622
配置MacVim,高亮+自动缩进+行号+折叠+优化
68834
通俗讲解 同步、异步、阻塞、非阻塞 编程
67754
三次握手，四次挥手，为什么是三次握手四次挥手
67519
gitlab-ci.yml 项目实战
65648
分类专栏
docker
付费
46篇
goLang
付费
73篇
php
付费
48篇
php笔试 | 面试题
付费
28篇
算法 / 数据结构
付费
15篇
goLang 笔试 | 面试题
8篇
Gin | iris
9篇
php拓展 | composer
16篇
Laravel
33篇
swoole | swoft
27篇
phpstorm | 单元测试
7篇
正则表达式
11篇
ffmpeg | mencoder
26篇
mysql | tidb
34篇
11篇
优化
12篇
redis | Lua
21篇
nginx
25篇
架构 | 设计模式
16篇
linux
36篇
shell脚本
13篇
ssh | rsync | nfs
16篇
vim | supervisor
9篇
服务安装
10篇
网络IO | 计算机原理
7篇
k8s | docker swarm
15篇
python
13篇
爬虫 | 机器学习
6篇
mongodb
12篇
javascript | html
7篇
jquery | TypeScript | RxJS
3篇
vue学习专栏
11篇
zabbix | prometheus
8篇
ElasticSearch
31篇
logstash | filebeat | kibana
16篇
RabbitMq
9篇
kafka | zookeeper
10篇
jenkins
10篇
git | gitlab
17篇
java
2篇
postman | jmeter
7篇
Fiddler | Vagrant | Autohotkey
15篇
mac | windows 使用技巧
9篇
最新评论
centos7 yum的卸载与安装
明想:
https://blog.csdn.net/weixin_45124488/article/details/105183699
完美解决 Could not find a version that satisfies the requirement 安装包名字 (from versions: )
#Crazydone:
Could not find a version that satisfies the requirement uWSGI==2.0.18 (from versions: 1.4.9, 1.4.10, 1.9, 1.9.1, 1.9.2, 1.9.3,
1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8, 1.9.9, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.15, 1.9.16, 1.9.17, 1.9.17.1, 1.9.18, 1.9.18.1
, 1.9.18.2, 1.9.19, 1.9.20, 1.9.21, 1.9.21.1, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.5.1, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.
0.11, 2.0.11.1, 2.0.11.2, 2.0.12, 2.0.13, 2.0.13.1, 2.0.14, 2.0.15, 2.0.16, 2.0.17, 2.0.17.1, 2.0.18, 2.0.19, 2.0.19.1, 2.0.20, 2.0.2
1)
完美解决 Could not find a version that satisfies the requirement 安装包名字 (from versions: )
LLcattttttt:
我的也是查询pip支持哪些符号的时候，提示模块没有'pep425tags'的描述。请问博主还能怎么查询啊？
完美解决 Could not find a version that satisfies the requirement 安装包名字 (from versions: )
@止于至善:
ERROR: Could not find a version that satisfies the requirement flask-sqlachemy (from versions: none)
ERROR: No matching distribution found for flask-sqlachemy
这个咋办呢pip已经不能升级了
完美解决 Could not find a version that satisfies the requirement 安装包名字 (from versions: )
Helen_0726:
求问在colab中报这样的错怎么解决啊
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
Ubuntu 编译安装支持 nvidia gpu 驱动的 FFMPEG
FFmpeg 使用 Nvidia GPU 进行转码加速
使用 OpenTelemetry 零代码修改接收 SkyWalking 追踪数据
2022
12月
5篇
11月
5篇
10月
11篇
09月
7篇
08月
14篇
07月
17篇
06月
20篇
05月
18篇
04月
13篇
03月
10篇
02月
7篇
01月
1篇
2021年218篇
2020年394篇
2016年4篇
2015年5篇
目录
目录
分类专栏
docker
付费
46篇
goLang
付费
73篇
php
付费
48篇
php笔试 | 面试题
付费
28篇
算法 / 数据结构
付费
15篇
goLang 笔试 | 面试题
8篇
Gin | iris
9篇
php拓展 | composer
16篇
Laravel
33篇
swoole | swoft
27篇
phpstorm | 单元测试
7篇
正则表达式
11篇
ffmpeg | mencoder
26篇
mysql | tidb
34篇
11篇
优化
12篇
redis | Lua
21篇
nginx
25篇
架构 | 设计模式
16篇
linux
36篇
shell脚本
13篇
ssh | rsync | nfs
16篇
vim | supervisor
9篇
服务安装
10篇
网络IO | 计算机原理
7篇
k8s | docker swarm
15篇
python
13篇
爬虫 | 机器学习
6篇
mongodb
12篇
javascript | html
7篇
jquery | TypeScript | RxJS
3篇
vue学习专栏
11篇
zabbix | prometheus
8篇
ElasticSearch
31篇
logstash | filebeat | kibana
16篇
RabbitMq
9篇
kafka | zookeeper
10篇
jenkins
10篇
git | gitlab
17篇
java
2篇
postman | jmeter
7篇
Fiddler | Vagrant | Autohotkey
15篇
mac | windows 使用技巧
9篇
目录
评论 2
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
戴国进
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值