MySQL VARCHAR 最佳长度评估实践

你的 VARCHAR 长度合适么？

作者：官永强，爱可生 DBA 团队成员，擅长 MySQL 运维方面的技能。热爱学习新知识，亦是个爱打游戏的宅男。

作者：李富强，爱可生 DBA 团队成员，熟悉 MySQL，TiDB，OceanBase 等数据库。相信持续把对的事情做好一点，会有不一样的收获。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 2200 字，预计阅读需要 8 分钟。

背景描述

有客户反馈，他们对一个 VARCHAR 类型的字段进行长度扩容。第一次可以很快就可以修改好，但是第二次却需要执行很久。比较疑惑明明表中的数据量是差不多的，为什么从 VARCHAR(20) 调整为 VARCHAR(50) 就比较快，但是从 VARCHAR(50) 调整为 VARCHAR(100) 就需要执行很久呢？ 于是我们对该情况进行场景复现并进行问题分析。

环境信息

本次验证涉及到的产品及版本信息如下：

产品版本
MySQL5.7.25-log MySQL Community Server (GPL)
Sysbenchsysbench 1.0.17

场景复现

3.1 数据准备

mysql> show create table test.sbtest1;
+---------+----------------------------------------+
| Table   | Create Table                           |
+---------+----------------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',`pad` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+---------+----------------------------------------+
1 row in set (0.00 sec)
mysql> select count(*) from test.sbtest1;
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+
1 row in set (0.10 sec)

3.2 问题验证

模拟客户的描述，我们对字段 c 进行修改，将 VARCHAR(20) 修改为 VARCHAR(50) 后再修改为 VARCHAR(100)，并观察其执行所需时间，以下是相关的操作命令以及执行结果：

mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(50);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> show create table test.sbtest1;
+---------+-------------------------------+
| Table   | Create Table                  |
+---------+-------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(50) COLLATE utf8mb4_bin DEFAULT NULL,`pad` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+---------+--------------------------------------------------------+
1 row in set (0.00 sec)mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(100);
Query OK, 1000000 rows affected (4.80 sec)
Records: 1000000  Duplicates: 0  Warnings: 0mysql> show create table test.sbtest1;
+---------+---------------------------+
| Table   | Create Table              |
+---------+---------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,`pad` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+---------+------------------------------------------------------------------------+
1 row in set (0.00 sec)

通过验证发现，该问题会稳定复现，故继续尝试去修改，最终发现在修改 VARCHAR(63) 为 VARCHAR(64) 时需要执行很久，但在 64 之后继续进行长度扩容发现可以很快完成。

mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(63);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(64);
Query OK, 1000000 rows affected (4.87 sec)
Records: 1000000  Duplicates: 0  Warnings: 0mysql> show create table test.sbtest1;
+---------+---------------+
| Table   | Create Table  |
+---------+---------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,`pad` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+---------+------------------------------------------------------------------------+
1 row in set (0.00 sec)mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(65);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(66);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

3.3 问题分析

对于 VARCHAR(63) 修改为 VARCHAR(64) 需要执行很久的这个情况进行分析。通过查阅官方文档 发现，由于 VARCHAR 字符类型在字节长度为 1 时可存储的字符为 0~255。当前字符集类型为 UTF8MB4，由于 UTF8MB4 为四字节编码字符集，即一个字节长度可存储 63.75（255/4）个字符，所以当我们将 VARCHAR(63) 修改为 VARCHAR(64) 时，需要增加一个字节去进行数据的存储，就要通过建立临时表的方式去完成本次长度扩容，故需要花费大量时间。

拓展验证

4.1 数据准备

mysql> show create table test_utf8.sbtest1;
+---------+----------------------------------------+
| Table   | Create Table                           |
+---------+----------------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(20) NOT NULL DEFAULT '',`pad` varchar(20) NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8 |
+---------+------------------+
1 row in set (0.00 sec)mysql> select count(*) from test_utf8.sbtest1;
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+
1 row in set (0.10 sec)

4.2 UTF8 场景验证

由于 UTF8 为三字节编码字符集，即一个字节可存储 85（255/3=85）个字符。

本次修改顺序：VARCHAR(20)→VARCHAR(50)→VARCHAR(85)，并观察其执行所需时间，以下是相关的操作命令以及执行结果：

mysql>  ALTER TABLE test_utf8.sbtest1 MODIFY c VARCHAR(50) ,algorithm=inplace,lock=none;
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> ALTER TABLE test_utf8.sbtest1 MODIFY c VARCHAR(85) ,algorithm=inplace,lock=none;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> show create table test_utf8.sbtest1;
+---------+-------------------------------+
| Table   | Create Table                  |
+---------+-------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(85) DEFAULT NULL,`pad` varchar(20) NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8 |
+---------+--------------------------------------------------+
1 row in set (0.00 sec)

修改顺序：VARCHAR(85)→VARCHAR(86)→VARCHAR(100)，此时我们会观察到执行的 SQL 语句直接返回报错。于是我们删除 algorithm=inplace ,lock=none 这两个参数，即允许本次 SQL 创建临时表以及给目标表上锁，然后重新执行 SQL，以下是相关的操作命令以及执行结果：

mysql> ALTER TABLE test_utf8.sbtest1 MODIFY c VARCHAR(86) ,algorithm=inplace,lock=none;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.mysql> ALTER TABLE test_utf8.sbtest1 MODIFY c VARCHAR(86);
Query OK, 1000000 rows affected (4.94 sec)
Records: 1000000  Duplicates: 0  Warnings: 0mysql> show create table test_utf8.sbtest1;
+---------+-------------------------------+
| Table   | Create Table                  |
+---------+-------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(86) DEFAULT NULL,`pad` varchar(20) NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8 |
+---------+--------------------------------------------------+
1 row in set (0.00 sec)mysql> ALTER TABLE test_utf8.sbtest1 MODIFY c VARCHAR(100) ,algorithm=inplace,lock=none;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0

4.3 UTF8MB4 场景验证

由于 UTF8MB4 为四字节编码字符集，即一个字节长度可存储 63（255/4=63.75）个字符。

本次修改顺序：VARCHAR(20)→VARCHAR(50)→VARCHAR(63)，并观察其执行所需时间，以下是相关的操作命令以及执行结果：

mysql>  ALTER TABLE test.sbtest1 MODIFY c VARCHAR(50) ,algorithm=inplace,lock=none;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(63) ,algorithm=inplace,lock=none;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0mysql> show create table test.sbtest1;
+---------+-------------------------+
| Table   | Create Table           |
+---------+-------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(63) COLLATE utf8mb4_bin DEFAULT NULL,`pad` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+---------+-------------------------------------------------------------------------+
1 row in set (0.00 sec)

本次修改顺序：VARCHAR(63)→VARCHAR(64)→VARCHAR(100)，此时我们会观察到执行的 SQL 语句直接返回报错。于是我们删除 algorithm=inplace, lock=none 这两个参数，即允许本次 SQL 创建临时表以及给目标表上锁，然后重新执行 SQL，以下是相关的操作命令以及执行结果：

mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(64) ,algorithm=inplace,lock=none;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(64) ;
Query OK, 1000000 rows affected (4.93 sec)
Records: 1000000  Duplicates: 0  Warnings: 0mysql> show create table test.sbtest1;
+---------+--------------------------+
| Table   | Create Table             |
+---------+--------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,`pad` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+---------+-------------------------------------------------------------------------+
1 row in set (0.00 sec)mysql> ALTER TABLE test.sbtest1 MODIFY c VARCHAR(100) ,algorithm=inplace,lock=none;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0

4.4 对比分析

字符长度修改UTF8(MB3)UTF8MB4
20->50online ddl (inplace)online ddl (inplace)
50->100online ddl (copy)online ddl (copy)
X->Y当Y*3<256 时，inplace
当X*3>=256，inplace		当 Y*4<256 时，inplace
当 X*4>=256，inplace
备注一个字符最大占用 3 个字节一个字符最大占用 4 个字节

结论

当一个字段的最大字节长度 >=256 字符时，需要 2 个字节来表示字段长度。

使用 UTF8MB4 举例：

  • 对于字段的最大字节长度在 256 字符内变化 (即 x*4<256 且 Y*4<256)，online ddl 走 inplace 模式，效率高。
  • 对于字段的最大字节长度在 256 字符外变化 (即 x*4>=256 且 Y*4>=256) ，online ddl 走 inplace 模式，效率高。
  • 否则，online ddl 走 copy 模式，效率低.
  • UTF8(MB3) 同理。

建议

为避免由于后期字段长度扩容，online ddl 走效率低的 copy 模式，建议：

  • 对于 UTF8(MB3) 字符类型：
    • 字符个数小于 50 个，建议设置为 VARCHAR(50) 或更小的字符长度。
    • 字符个数接近 84（256/3=83.33）个，建议设置为varchar(84)或更大的字符长度。
  • 对于 UTF8MB4 字符类型：
    • 字符个数小于 50 个，建议设置为 VARCHAR(50)，或更小的字符长度。
    • 字符个数接近 64（256/4=64）个，建议设置为 VARCHAR(64) 或更大的字符长度。

本次验证结果仅供参考，若您需要在生产环境中进行操作，请结合实际情况合理定义 VARCHAR 的长度，避免造成经济损失。

更多技术文章，请访问：https://opensource.actionsky.com/

关于 SQLE

SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。

SQLE 获取

类型地址
版本库https://github.com/actiontech/sqle
文档https://actiontech.github.io/sqle-docs/
发布信息https://github.com/actiontech/sqle/releases
数据审核插件开发文档https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse

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

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

相关文章

Go微服务精讲：Go-Zero全流程实战即时通讯(超清)

Go微服务精讲：Go-Zero全流程实战即时通讯(超清)

go-zero 是一个集成了各种工程实践的 web 和 rpc 框架。通过弹性设计保障了大并发服务端的稳定性&#xff0c;经受了充分的实战检验。 Go微服务精讲&#xff1a;Go-Zero全流程实战即时通讯(超清) go-zero 中的 api&#xff0c;rpc&#xff0c;数据库等涉及的代码&#xff0c;…
阅读更多...
C#标签设计打印软件开发

C#标签设计打印软件开发

1、新建自定义C#控件项目Custom using System; using System.Collections.Generic; using System.Text;namespace CustomControls {public class CommonSettings{/// <summary>/// 把像素换算成毫米/// </summary>/// <param name"Pixel">多少像素…
阅读更多...
Springboot 集成 Consul 实现服务注册中心-05

Springboot 集成 Consul 实现服务注册中心-05

因为后续很多模块都要用到注册中心&#xff0c;所以此处先实现此模块。 Consul简介 Consul是一个开源的服务发现和配置管理工具&#xff0c;具有跨平台、运行高效等特点。它由HashiCorp公司开发&#xff0c;并使用Go语言编写。Consul主要用于实现分布式系统中的服务发现、健康…
阅读更多...
解决Node.js mysql客户端不支持认证协议引发的“ER_NOT_SUPPORTED_AUTH_MODE”问题

解决Node.js mysql客户端不支持认证协议引发的“ER_NOT_SUPPORTED_AUTH_MODE”问题

这是一个版本问题 我用koa2和mysql2链接就没有问题 不知道这个老项目运行为啥有这个问题 解决方案 打开mysql运行这个两个命令&#xff1a; ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123321; FLUSH PRIVILEGES; 须知(给小白看的&#xff01;) …
阅读更多...
搜维尔科技：Senseglove Nova 数据手套触觉反馈测试

搜维尔科技：Senseglove Nova 数据手套触觉反馈测试

Senseglove Nova 数据手套触觉反馈测试 搜维尔科技&#xff1a;Senseglove Nova 数据手套触觉反馈测试
阅读更多...
PCB板上的Mark点

PCB板上的Mark点

PCB生产中Mark点设计 1.pcb必须在板长边对角线上有一对应整板定位的Mark点，板上集成电路引脚中心距小于0.65mm的芯片需在集成电路长边对角线上有一对对应芯片定位的Mark点；pcb双面都有贴片件时，则pcb的两面都按此条加Mark点。 2.pcb边需留5mm工艺边（机器夹持PCB最小间距要求…
阅读更多...
优立科技：从数字孪生到元宇宙

优立科技：从数字孪生到元宇宙

2021年10月&#xff0c;Facebook致力于发展元宇宙&#xff0c;并更名为Meta。加上此前Roblox上市的消息&#xff0c;让「元宇宙」一词迅速在2021年爆火&#xff0c;刺激了VR、游戏等相关产业的发展&#xff0c;甚至有人宣称2021年为「元宇宙『元年』」。然而&#xff0c;「元年…
阅读更多...
YOLOv8的训练、验证、预测及导出[目标检测实践篇]

YOLOv8的训练、验证、预测及导出[目标检测实践篇]

这一部分内容主要介绍如何使用YOLOv8训练自己的数据集&#xff0c;并进行验证、预测及导出&#xff0c;采用代码和指令的两种方式&#xff0c;参考自官方文档&#xff1a;Detect - Ultralytics YOLOv8 Docs。实践篇不需要关注原理&#xff0c;只需要把流程跑通就行&#xff0c;…
阅读更多...
信号产生的五种方式

信号产生的五种方式

文章目录 正文前的知识准备kill 命令查看信号man手册查看信号信号的处理方法 认识信号产生的5种方式1. 工具2. 键盘3. 系统调用kill 向任意进程发送任意信号raise 给调用方发送任意信号abort 给调用方发送SIGABRT信号 4. 软件条件5. 异常 正文前的知识准备 kill 命令查看信号 …
阅读更多...
Boost的日志库Log使用详解

Boost的日志库Log使用详解

项目中使用到了Boost日志库&#xff0c;今日来探索一下&#xff1a; #include"boost/log/trivial.hpp" #include"boost/log/sinks/text_file_backend.hpp" #include"boost/log/utility/setup/file.hpp" #include"boost/log/utility/setup/…
阅读更多...
构建 WebRTC 一对一信令服务器

构建 WebRTC 一对一信令服务器

构建 WebRTC 一对一信令服务器 构建 WebRTC 一对一信令服务器前言为什么选择 Nodejs&#xff1f;Nodejs 的基本原理浏览器使用 Nodejs安装 Nodejs 和 NPMsocket.io信令服务器搭建信令服务器客户端服务端启动服务器并测试 总结参考 构建 WebRTC 一对一信令服务器 前言 我们在学…
阅读更多...
【Node.js从基础到高级运用】二十八、Node.js 内存管理浅析

【Node.js从基础到高级运用】二十八、Node.js 内存管理浅析

Node.js 作为一个基于 Chrome V8 引擎的 JavaScript 运行环境&#xff0c;其性能和效率在很大程度上取决于内存管理的优劣。 1. Node.js 内存结构 在深入了解内存管理之前&#xff0c;我们需要先了解 Node.js 的内存结构。Node.js 的内存可以大致分为以下几个部分&#xff1a;…
阅读更多...
Jmeter页面汉化和字体显示过小调整

Jmeter页面汉化和字体显示过小调整

在频繁解压使用Jmeter的时候&#xff0c;经常会遇到需要将页面的英文调整为中文&#xff0c;页面文字和编辑区域内容文字显示较小的问题&#xff0c;记录一下方便以后查阅。 1.页面汉化 Jmeter在解压启动之后页面显示是英文&#xff0c;如果需要修改为中文&#xff0c;可以修改…
阅读更多...
uniapp的app端软件更新弹框

uniapp的app端软件更新弹框

1&#xff1a;使用html PLUS实现&#xff1a;地址HTML5 API Reference (html5plus.org)&#xff0c;效果图 2&#xff1a;在app.vue的onLaunch生命周期中&#xff0c;代码如下&#xff1a; onLaunch: function() {let a 0let view new plus.nativeObj.View(maskView, {backg…
阅读更多...
【WEEK11】学习目标及总结【Spring Boot】【中文版】

【WEEK11】学习目标及总结【Spring Boot】【中文版】

学习目标&#xff1a; 学习SpringBoot 学习内容&#xff1a; 参考视频教程【狂神说Java】SpringBoot最新教程IDEA版通俗易懂员工管理系统 页面国际化登录功能展示员工列表增加员工修改员工信息删除及404处理 学习时间及产出&#xff1a; 第十一周MON~SAT 2024.5.6【WEEK11】…
阅读更多...
YOLOv5改进 | 主干篇 | 2024.5全新的移动端网络MobileNetV4改进YOLOv5（含MobileNetV4全部版本改进）

YOLOv5改进 | 主干篇 | 2024.5全新的移动端网络MobileNetV4改进YOLOv5（含MobileNetV4全部版本改进）

一、本文介绍 本文给大家带来的改进机制是MobileNetV4&#xff0c;其发布时间是2024.5月。MobileNetV4是一种高度优化的神经网络架构&#xff0c;专为移动设备设计。它最新的改动总结主要有两点&#xff0c;采用了通用反向瓶颈&#xff08;UIB&#xff09;和针对移动加速器优化…
阅读更多...
AI烟雾监测识别摄像机：智能化安全防范的新利器

AI烟雾监测识别摄像机：智能化安全防范的新利器

随着现代社会的不断发展&#xff0c;人们对于安全问题的关注日益增加&#xff0c;尤其是在日常生活和工作中&#xff0c;对火灾等意外事件的预防成为了一项重要任务。为了更好地应对火灾风险&#xff0c;近年来&#xff0c;AI烟雾监测识别摄像机应运而生&#xff0c;成为智能化…
阅读更多...
【深度学习】实验1 波士顿房价预测

【深度学习】实验1 波士顿房价预测

波士顿房价预测 代码 import numpy as np import matplotlib.pyplot as pltdef load_data():# 1.从文件导入数据datafile D:\Python\PythonProject\sklearn\housing.datadata np.fromfile(datafile, sep )# 每条数据包括14项&#xff0c;其中前面13项是影响因素&#xff0c…
阅读更多...
【代码随想录算法训练Day1】LeetCode 704.二分查找、LeetCode 27.移除元素

【代码随想录算法训练Day1】LeetCode 704.二分查找、LeetCode 27.移除元素

Day1 数组、二分 二分并不算难&#xff0c;但有个比较麻烦的点是处理区间端点&#xff0c;如果区间端点处理不当&#xff0c;就容易出现死循环的情况&#xff0c;所以在我们处理二分的时候&#xff0c;要特别注意端点的处理&#xff0c;判断边界满足条件是严格不等或是大于等于…
阅读更多...
Windows (exe) 、Windows ARM64 (exe) 、Windows ZlP Archive (win.zip)，请问他们的区别是什么？

Windows (exe) 、Windows ARM64 (exe) 、Windows ZlP Archive (win.zip)，请问他们的区别是什么？

这三种文件格式都是用于Windows操作系统的软件或数据分发方式&#xff0c;它们的主要区别如下&#xff1a; 1.Windows (exe): 这通常是一个可执行文件&#xff0c;直接在Windows操作系统上运行。用户下载后双击即可安装或运行软件。它可能是一个安装程序&#xff0c;会在安装过…
阅读更多...
最新文章

Copyright @ 2022~2023