流苏小筑
type: channel
link: https://mlsll.cn/
description: 步伐虽小，密而不止
items: 设置wls2自动使用宿主机代理网络
items: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? (Details: [13] 权限不够)
items: 在Deepin系统中为AppImage应用添加图标并集成到应用程序菜单
items: 在Linux系统中使用alist和rclone将云盘挂载在本地系统
items: 通过本机ip地址访问wsl2容器中的服务
items: 事务基础知识
items: 数据库的设计规范
items: 普通索引 vs 唯一索引
items: 索引下推
items: 优先考虑覆盖索引

设置wls2自动使用宿主机代理网络
type: item
date: 2025-10-31T11:36:17+08:00
description: 在win11系统下的用户目录C:\Users\Choba下创建.wslconfig文件,写入如下内容[wsl2] networkingMode=mirrored保存后重启电脑

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? (Details: [13] 权限不够)
type: item
date: 2025-06-24T11:20:13+08:00
description: 这个 "权限不够" 错误表明您的用户账户没有访问 Docker 守护进程所需的权限。以下是完整的解决方案：永久解决方案：将用户加入 docker 组1. 将您的用户添加到 docker 用户组sudo usermod -aG docker $USER2. 刷新当前用户组设置（不需要注销）newgrp docker3. 验证权限docker ps # 应能正常执行不报错临时解决方案：更改 Docker socket 权限（不推荐）临时更改权限（重启后失效）sudo chmod 666 /var/run/docker.sock永久更改权限（安全风险）sudo chmod a+rw /var/run/docker.sock

在Deepin系统中为AppImage应用添加图标并集成到应用程序菜单
type: item
date: 2025-05-07T14:10:00+08:00
description: 1. 准备图标文件下载或创建.png图标（推荐尺寸 512x512 或 256x256），例如：wget -O ~/.local/share/icons/myapp.png https://example.com/icon.png或从AppImage自身提取图标：./YourApp.AppImage --appimage-extract # 解压后从squashfs-root目录获取图标2. 创建.desktop桌面文件在 ~/.local/share/applications/ 目录下创建文件（例如 myapp.desktop）：nano ~/.local/share/applications/myapp.desktop填入以下内容（根据实际情况修改路径和名称）：[Desktop Entry] Version=1.0 Type=Application Name=Navicat-Lite Exec=/home/choba/opt/AppImage/navicat17-premium-lite/navicat17-premium-lite-cs-x86_64.AppImage Icon=/home/choba/opt/AppImage/navicat17-premium-lite/logo.png Categories=Utility;Development; Terminal=false StartupNotify=true3. 赋予AppImage执行权限chmod +x /path/to/YourApp.AppImage4. 刷新桌面数据库update-desktop-database ~/.local/share/applications/5. 验证效果在Deepin启动器中搜索应用名称或直接启动测试：gtk-launch myapp注意事项图标路径问题如果图标未显示，尝试使用绝对路径（如 Icon=/home/user/.local/share/icons/myapp.png）或将图标复制到系统目录：/usr/share/pixmaps/多用户共享应用 将.desktop和图标放到系统目录：sudo mv myapp.desktop /usr/share/applications/ sudo mv myapp.png /usr/share/icons/AppImage兼容性 某些AppImage可能需要--no-sandbox等参数，在Exec行添加：Exec=/path/to/app --no-sandbox %U

在Linux系统中使用alist和rclone将云盘挂载在本地系统
type: item
date: 2025-04-16T18:23:00+08:00
description: 引言随着云存储服务的普及，用户常常需要同时管理多个云盘（如阿里云盘、Google Drive、OneDrive 等）。如果能够将这些云存储统一挂载到本地文件系统，就能像操作本地文件一样直接访问云端数据，极大地提升效率。本文将通过 AList 和 Rclone 工具，手把手教你实现这一目标。一、工具简介1. AList 是什么？AList官网AList 是一个开源的 多存储文件列表程序，支持 20+ 种云存储服务，可以将不同云盘整合到统一的 Web 界面中，并通过 WebDAV 协议暴露接口。2. Rclone 是什么？Rclone官网Rclone 是一个命令行工具，专为云存储设计，支持 挂载、同步、加密 等功能，能够将远程存储挂载为本地磁盘。二、准备工作Linux 发行版（如 Ubuntu/CentOS）已安装 Docker 和 Docker Compose（用于运行 AList）,这里使用docker,避免环境依赖版本问题。终端操作权限三、部署 AList 服务1. 使用 Docker Compose 安装 AList创建alist目录：mkdir -p /home/choba/alist && cd /etc/alist mkdir data nano docker-compose.yml粘贴以下内容：services: alist: image: xhofe/alist:latest container_name: alist volumes: - './data:/opt/alist/data' ports: - '5244:5244' environment: - PUID=0 - PGID=0 - UMASK=022 - TZ=Asia/Shanghai # 设置时区（可选） restart: unless-stopped启动容器：docker compose up -d2. 获取管理员密码v3.25.0 及以上版本随机生成密码：docker exec -it alist ./alist admin random手动设置密码（替换 NEW_PASSWORD）：docker exec -it alist ./alist admin set NEW_PASSWORDv3.25.0 以下版本docker exec -it alist ./alist admin3. 配置云存储访问 http://服务器IP:5244/@login，使用管理员账号登录。进入 「存储」 → 「添加」 ，选择云盘类型（如阿里云盘），填写 Token 或 OAuth 配置。保存后，AList 会通过 WebDAV 协议暴露存储路径（如 http://IP:5244/dav）。四、使用 Rclone 挂载到本地1. 安装 Rclone# 一键安装脚本 curl https://rclone.org/install.sh | sudo bash # 或者使用apt安装 sudo apt install rclone2. 配置 Rclone 连接 AList 的 WebDAV╭─    ~/rclone-v1.69.1-linux-amd64 ··············································· ✔  at 17:06:19  ─╮ ╰─ rclone config ─╯ <5>NOTICE: Config file "/home/choba/.config/rclone/rclone.conf" not found - using defaults No remotes found, make a new one? n) New remote s) Set configuration password q) Quit config n/s/q> n Enter name for new remote. name> remote Option Storage. Type of storage to configure. Choose a number from below, or type in your own value. 1 / 1Fichier \ (fichier) 2 / Akamai NetStorage \ (netstorage) 3 / Alias for an existing remote \ (alias) 4 / Amazon Drive \ (amazon cloud drive) 5 / Amazon S3 Compliant Storage Providers including AWS, Alibaba, Ceph, China Mobile, Cloudfla…

通过本机ip地址访问wsl2容器中的服务
type: item
date: 2025-03-05T18:09:00+08:00
description: 问题:想搭建一个本地的接口文档服务器，在局域网内使用，使用的是wsl2+docker，搭建完成后可以使用localhost:端口号访问，但是不能通过本机ip进行访问。找了很多文档，修改防火墙规则，更改桥接模式，关闭虚拟机防火墙等等，都不行。 按官方文档说最新的wsl2是支持镜像模式的，wsl2和宿主机ip是一致的，可以直接进行访问，但是不行，后面试了很多方法，发现是因为使用1pan的时候将docker的iptables设置为true了。解决方法编辑/etc/docker/daemon.json文件添加如下内容{ "iptables": false }开放防火墙 管理员权限打开PowerShell运行# 可以通过这个命令获取40E0AC32-46A5-438A-A0B2-2B479E8F2E90 Get-NetFirewallHyperVVMSetting | Format-Table Name, Id -AutoSize Set-NetFirewallHyperVVMSetting -Name ‘{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}’ -DefaultInboundAction Allow3.编辑wslconfig开启镜像网络 wsl-configwin + r 输入 %UserProfile% 新建 .wslconfig 建议内容如下[wsl2] memory=8GB #内存最大值 swap=8GB #虚拟内存最大值 processors=4 #cpu核最大值 networkingMode=mirrored # 开启镜像网络 dnsTunneling=true # 开启 DNS Tunneling firewall=true # 开启 Windows 防火墙 autoProxy=true # 开启自动同步代理 [experimental] sparseVhd=true # 开启自动释放 WSL2 虚拟硬盘空间 autoMemoryReclaim=gradual # 开启自动回收内存 hostAddressLoopback=true # 允许容器通过分配给主机的 IP 地址连接到主机重启wsl就可通过宿主机ip进行访问。

事务基础知识
type: item
date: 2024-06-24T10:00:00+08:00
description: 1. 数据库事务概述1.1 存储引擎支持情况SHOW ENGINES 命令来查看当前 MySQL 支持的存储引擎都有哪些，以及这些存储引擎是否支持事务。 能看出在 MySQL 中，只有InnoDB 是支持事务的。1.2 基本概念事务：一组逻辑操作单元，使数据从一种状态变换到另一种状态。 事务处理的原则：保证所有事务都作为 一个工作单元 来执行，即使出现了故障，都不能改变这种执行方 式。当在一个事务中执行多个操作时，要么所有的事务都被提交( 存下来；要么数据库管理系统将 放弃 所作的所有 commit )，那么这些修改就 永久 地保 修改 ，整个事务回滚( rollback )到最初状态。# 案例：AA用户给BB用户转账100 update account set money = money - 100 where name = 'AA'; # 服务器宕机 update account set money = money + 100 where name = 'BB';1.3 事务的ACID特性原子性（atomicity）：原子性是指事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。一致性（consistency）： 一致性是指事务执行前后，数据从一个 合法性状态 变换到另外一个 合法性状态 。这种状态 是 语义上 的而不是语法上的，跟具体的业务有关。隔离型（isolation）： 事务的隔离性是指一个事务的执行 不能被其他事务干扰，即一个事务内部的操作及使用的数据对 并发 的其他事务是隔离的，并发执行的各个事务之间不能相互干扰。 持久性（durability）： 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是 永久性的 ，接下来的其他操作和数据库 故障不应该对其有任何影响。 持久性是通过 事务日志 来保证的。日志包括了 重做日志 和 回滚日志 。当我们通过事务对数据进行修 改 的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样 做 的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新 执 行，从而使事务具有持久性。总结：ACID是事务的四大特征，在这四个特性中，原子性是基础，隔离性是手段，一致性是约束条件， 而持久性是我们的目的。 数据库事务，其实就是数据库设计者为了方便起见，把需要保证 原子性、 隔离性、 一致性 和 持久性 的一个或多个数据库操作称为一个事务1.4 事务的状态我们现在知道 事务 是一个抽象的概念，它其实对应着一个或多个数据库操作，MySQL根据这些操作所 执 行的不同阶段把 事务 大致划分成几个状态：活动的（active） 事务对应的数据库操作正在执行过程中时，我们就说该事务处在部分提交的（partially committed） 当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并 没有刷新到磁盘 时，我们就说该事务处在 部分提交的 状态。失败的（failed） 当事务处在 活动的 或者 部分提交的 状态时，可能遇到了某些错误（数据库自身的错误、操作系统 错误或者直接断电等）而无法继续执行，或者人为的停止当前事务的执行，我们就说该事务处在 失 败的 状态。中止的（aborted） 如果事务执行了一部分而变为 失败的 状态，那么就需要把已经修改的事务中的操作还原到事务执 行前的状态。换句话说，就是要撤销失败事务对当前数据库造成的影响。我们把这个撤销的过程称 之为 回滚 。当 回滚 操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我们就说该 事 务处在了 中止的 状态。 举例：UPDATE accounts SET money = money - 50 WHERE NAME = 'AA'; UPDATE accounts SET money = money + 50 WHERE NAME = 'BB';提交的（committed）当一个处在 部分提交的 状态的事务将修改过的数据都 在了 提交的 状态。 一个基本的状态转换图如下所示： 图中可见，只有当事务处于 提交的或者 中止的状态时，一个事务的生命周期才算是结束了。对于 已经提交的事务来说，该事务对数据库所做的修改将永久生效，对于处于中止状态的事务，该事务 对数据库所做的所有修改都会被回滚到没执行该事务之前的状态。2. 如何使用事务使用事务有两种方式，分别为 显式事务 和 隐式事务 。2.1 显式事务步骤1： START TRANSACTION 或者 BEGIN ，作用是显式开启一个事务。mysql> BEGIN; #或者 mysql> START TRANSACTION;START TRANSACTION 语句相较于 BEGIN 特别…

数据库的设计规范
type: item
date: 2024-06-22T10:00:00+08:00
description: 1. 为什么需要数据库设计我们在设计数据表的时候，要考虑很多问题。比如：用户都需要什么数据？需要在数据表中保存哪些数据？如何保证数据表中数据的正确性，当插入、删除、更新的时候该进行怎样的约束检查？如何降低数据表的数据冗余度，保证数据表不会因为用户量的增长而迅速扩张？如何让负责数据库维护的人员更方便地使用数据库？使用数据库的应用场景也各不相同，可以说针对不同的情况，设计出来的数据表可能千差万别。现实情况中，面临的场景：当数据库运行了一段时间之后，我们才发现数据表设计的有问题。重新调整数据表的结构，就需要做数据迁移，还有可能影响程序的业务逻辑，以及网站正常的访问。如果是糟糕的数据库设计可能会造成以下问题：数据冗余、信息重复，存储空间浪费数据更新、插入、删除的异常无法正确表示信息丢失有效信息程序性能差良好的数据库设计则有以下优点：节省数据的存储空间能够保证数据的完整性方便进行数据库应用系统的开发总之，开始设置数据库的时候，我们就需要重视数据表的设计。为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。2. 范 式2.1 范式简介在关系型数据库中，关于数据表设计的基本原则、规则就称为范式。可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别 。要想设计一个结构合理的关系型数据库，必须满足一定的范式。2.2 范式都包括哪些目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是：第一范式（1NF）、第二范式 （2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美 范式）。数据库的范式设计越高阶，夯余度就越低，同时高阶的范式一定符合低阶范式的要求，满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范的要求称为第二范式（2NF），其余范式以此类推。一般来说，在关系型数据库设计中，最高也就遵循到 BCNF , 普遍还是3NF 。但也不绝对，有时候为了提 高某些查询性能，我们还需要破坏范式规则，也就是反规范化。 2.3 键和相关属性的概念范式的定义会使用到主键和候选键，数据库中的键(Ky)由一个或者多个属性组成。数据表中常用的几种键和属性的定义：超键：能唯一标识元组的属性集叫做超键。候选键：如果超键不包括多余的属性，那么这个超键就是候选键。主键：用户可以从候选键中选择一个作为主键。外键：如果数据表R1中的某属性集不是R1的主键，而是另一个数据表R2的主键，那么这个属性集就是数据表R1的外键。主属性：包含在任一候选键中的属性称为主属性。非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性。通常，我们也将候选键称之为“码”，把主键也称为“主码”。因为键可能是由多个属性组成的，针对单个属性，我们还可以用主属性和非主属性来进行区分。2.4 第一范式(1st NF)第一范式主要确保数据库中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为 拆分的最小数据单元。 不可再次我们在设计某个字段的时候，对于字段X来说，不能把字段X拆分成字段X-1和字段X-2。事实上，任何的 DBMS都会满足第一范式的要求，不会将字段进行拆分。 举例：user 表的设计不符合第一范式 其中，user_info字段为用户信息，可以进一步拆分成更小粒度的字段，不符合数据库设计对第一范式的 要求。将user_info拆分后如下： 2.5 第二范式(2nd NF)第二范式要求，在满足第一范式的基础上，还要满足数据库里的每一条数据记录，都是可唯一标识的。 而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。如果知道主键的所有属性的 值，就可以检索到任何元组（行）的任何属性的任何值。（要求中的主键，其实可以扩展替换为候选 键）。 举例1： 成绩表 （学号，课程号，成绩）关系中，（学号，课程号）可以决定成绩，但是学号不能决定成绩，课 程号也不能决定成绩，所以“（学号，课程号）→成绩”就是完全依赖关系 。 举例2： 比赛表 player_game ，里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性，这 里候选键和主键都为（球员编号，比赛编号），我们可以通过候选键（或主键）来决定如下的关系：(球员编号, 比赛编号) → (姓名, 年龄, 比赛时间, 比赛场地，得分)但是这个数据表不满足第二范式，因为数据表中的字段之间还存在着如下的对应关系： (球员编号) → (姓名，年龄) (比赛编号) → (比赛时间, 比赛场地)对于非主属性来说，并非完全依赖候选键。这样会产生怎样的问题呢？数据冗余 ：如果一个球员可以参加 m 场比赛，那么球员的姓名和年龄就重复了 m-1 次。一个比赛 也可能会有 n 个球员参加，比赛的时间和地点就重复了 n-1 次。插入异常 ：如…

普通索引 vs 唯一索引
type: item
date: 2024-06-01T22:00:00+08:00
description: 普通索引 vs 唯一索引 在不同的业务场景下，应该选择普通索引，还是唯一索引？假设你在维护一个居民系统，每个人都有一个唯一的身份证号，而且业务代码已经保证了不会写入两个重复的身份证号。如果居民系统需要按照身份证号查姓名：select name from CUser where id_card ='xxxxxxxyyyyyyzzzzz';所以，你一定会考虑在id_card字段上建索引。由于身份证号字段比较大，不建议把身份证号当做主键。现在有两个选择，要么给id_card字段创建唯一索引，要么创建一个普通索引。如果业务代码已经保证了不会写入重复的身份证号，那么这两个选择逻辑上都是正确的。从性能的角度考虑，你选择唯一索引还是普通索引呢？选择的依据是什么呢？ 假设，我们有一个主键列为ID的表，表中有字段k，并且在k上有索引，假设字段 k 上的值都不重复。 这个表的建表语句是： create table test( id int primary key, k int not null, name varchar(16), index (k) )engine=InnoDB;表中R1~R5的(ID,k)值分别为(100,1)、(200,2)、(300,3)、(500,5)和(600,6)。1 查询过程 假设，执行查询的语句是 select id from test where k=5。 对于普通索引来说，查找到满足条件的第一个记录(5,500)后，需要查找下一个记录，直到碰到第一个不满足k=5条件的记录。对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检 索。那么，这个不同带来的性能差距会有多少呢？答案是， 微乎其微 。 你知道的，noDB的数据是按数据页为单位来读写的。也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。在noDB中，每个数据页的大小默认是16KB。因为引擎是按页读写的，所以说，当找到k=5的记录的时候，它所在的数据页就都在内存里了。那么，对于普通索引来说，要多做的那一次“查找和判断下一条记录”的操作，就只需要一次指针寻找和一次计算。当然，如果k=5这个记录刚好是这个数据页的最后一个记录，那么要取下一个记录，必须读取下一个数据页，这个操作会稍微复杂一些。但是，我们之前计算过，对于整型字段，一个数据页可以放近千个ky，因此出现这种情况的概率会很低。所以我们计算平均性能差异时，仍可以认为这个操作成本对于现在的CPU来说可以忽略不计。2 更新过程 为了说明普通索引和唯一索引对更新语句性能的影响这个问题，介绍一下change buffer。当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话， 在不影响数据一致性的前提下， InooDB会将这些更新操作缓存在change buffer中 ，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。 将change buffer中的操作应用到原数据页，得到最新结果的过程称为 merge 。除了 访问这个数据页 会 触 发merge外，系统有后台线程会定期 merge。在 数据库正常关闭（shutdown） 的过程中，也会执行 merge 操作。 如果能够将更新操作先记录在change buffer， 减少读磁盘 ，语句的执行速度会得到明显的提升。而 且， 数据读入内存是需要占用 buffer pool 的，所以这种方式还能够 避免占用内存 ，提高内存利用率。那么，什么条件下可以使用change bufferl呢？对于唯一索引来说，所有的更新操作都要先判断这个操作是否违反唯一性约束。比如，要插入(4,400这个记录就要先判断现在表中是否已经存在k二4的记录，而这必须要将数据页读入内存才能判断。如果都已经读入到内存了，那直接更新内存会更快，就没必要使用change buffer了。因此，唯一索引的更新就不能使用change buffer,实际上也只有普通索引可以使用。change buffer用的是buffer pool里的内存，因此不能无限增大。change buffer的大小，可以通过参数innodb_change_buffer_max_size来动态设置。这个参数设置为58的时候，表示change buffer的大小最多只能占用ouffer pool的50%。如果要在这张表中插入一个新记录(4,400)的话，nnoDB的处理流程是怎样的？第一种情况是，这个记录要更新的目标页在内存中。这时：对于唯一索引来说，找到3和5之间的位置，判断为…

索引下推
type: item
date: 2024-05-21T16:00:00+08:00
description: 索引下推 (就是不着急回表，减少回表数量)更多的是在联合索引使用Index Condition Pushdown(ICP)是MySQL 5.6中新特性，是一种在存储引擎层使用索引过滤数据的一种优化方式。ICP可以减少存储引擎访问基表的次数以及MySQL服务器访问存储引擎的次数。1 使用前后的扫描过程 在不使用ICP索引扫描的过程： storage层：只将满足index key条件的索引记录对应的整行记录取出，返回给server层 server 层：对返回的数据，使用后面的where条件过滤，直至返回最后一行。 使用ICP扫描的过程： storage层： 首先将index key条件满足的索引记录区间确定，然后在索引上使用index filter进行过滤。将满足的index filter条件的索引记录才去回表取出整行记录返回server层。不满足index filter条件的索引记录丢弃，不回 表、也不会返回server层。 server 层： 对返回的数据，使用table filter条件做最后的过滤。 使用前后的成本差别 使用前存储层多返回了需要被index filter过滤掉的整行记录 使用ICP后直接就去掉了不满足index filter条件的记录，省去了他们回表和传递到server层的成本。 ICP的 加速效果取决于在存储引擎内通过 ICP筛选 掉的数据的比例。10.2 ICP的使用条件 ①只能用于二级索引(secondary index)②explain显示的执行计划中type值（join 类型）为 range 、 ref 、 eq_ref 或者 ref_or_null 。 ③并非全部where条件都可以用ICP筛选，如果where条件的字段不在索引列中，还是要读取整表的记录 到server端做where过滤。④ICP可以用于MyISAM和InnnoDB存储引擎 ⑤MySQL 5.6版本的不支持分区表的ICP功能，5.7版本的开始支持。⑥当SQL使用覆盖索引时，不支持ICP优化方法。

优先考虑覆盖索引
type: item
date: 2024-05-06T10:00:00+08:00
description: 什么是覆盖索引？理解方式一：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它 不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数 据，那就不需要读取行了。一个索引包含了满足查询结果的数据就叫做覆盖索引。理解方式二：非聚簇复合索引的一种形式，它包括在查询里的SELECT、JOIN和WHERE子句用到的所有 列 （即建索引的字段正好是覆盖查询条件中所涉及的字段）。 简单说就是， 索引列+主键 包含 SELECT 到 FROM之间查询的列 。 举例：select age from studen where age > 123;覆盖索引的利弊好处：1.避免Innodb表进行索引的二次查询（回表）2.可以把随机I/O变成顺序I/O加快查询效率弊端：索引字段的维护总是有代价的。因此，在建立冗余索引来支持覆盖索引时就需要权衡考虑了。这是业务DBA,或者称为业务数据架构师的工作。