mariadb 数据安装目录

p g c q 的 书已经到了，项目实战更新完成之后， p g c q 就 会加入到实战手册当中。这个视频来看一下 marry db 的 安装，首先需要来安装一下它的依赖， 由于这个 marry db 它是从 micro 衍生出来的，那么这里它和 micro 需要的依赖是一样的， 安装方式上基本也一样，没有什么区别。接着来添加一个 micro 的 组，添加完成之后再来添加一个 micro 的 用户。 这些都做完成之后，那么我们就可以把解压后的这个文件复制到 u s m local 目录下面，我这里就直接把它移过去了， 移过去之后直接 cd u z 拷拷口进入到这个目录来，那么这里接着还要来创建一个它的配置文件， 这里我把几个命令合在一起了。首先来创建这个配置文件名称，然后把它的执行权限改成 root， 哦，把它的数值和数值都改成 root， 紧接着把它的执行权限改成六四四。 然后这里就对这个配置文件里面追加一些内容，就是以 micro 这个用户的身份进行运行，端口是三三零六，这个是它的一个数据目录。这些都做完成之后，那么就可以来粗化。 初识化这个 marry db 的 话非常快，这里的话它执行完成之后，你往上面滑一点，它这里会出现一个 ok 的 字样，如果出现这样的话，那么就初识化成功。 初识化成功之后，这里你就进入到 get 这个目录了，它这里有个错误的日期文件，它的密码就在这里面使用 get 来查看。 哎，我去这里翻车了，它没在这里，那它的密码应该是默认就是为空的，那么接着来启动 这里，它这有个文件，里面有个 my sql server， 然后撕到开始，这样呢就启动起来， 启动完成之后，那么就可以来进行登录，登录之前还要做一下判断，来看一下它这个有没有启动起来， 可以看到这些已经启动起来了这个进程，那么这里来登录一下，试一下 他这也使用这一个。 好，可以看到它这个默认是没有密码的，那么登录进来之后，你就可以自己去改一下它的密码。

二零二六年， perk 纳放出了一份七百多组数据的性能报告， mysql 生态炸了锅， maria d b 十二点一在高病发场景下，读写性能暴跌百分之二十八。 这不是版本回推的 bug， 而是一次有意为之的架构精简，但代价远超预期。今天我们就来拆解这百分之二十八到底丢在了哪里。 ysql 和 maria db 都是从同一个 inno db 引擎分叉出来的，按理说底层都是同一套 btree 加缓充值的架构，性能不应该差太多。但 perkmin 这次测出来的数据告诉我们，在六十四县城以上，差距不是一点半点，而是断崖式的。 问题出在哪？答案藏在缓冲池的三个关键改动力。打个比方，两家超市从同一个批发市场进货，一家请了专业团队分区管理货架，高峰期各管各的，互不干扰。 另一家觉得这套配置太复杂，精简成了一个人管，所有货架平时没什么差别，但到了促销日，所有顾客挤在同一个过道抢货，效率直接崩盘。这就是 maria d b 在 高并发下的真实处境。 先认识一下这份报告的幕后推手， peter zitsaf， perkina 的 创人和 ceo， mysql 性能优化领域的标杆人物。 他们团队这次的测试规模是史无前例的。四个数据库版本，三种缓冲池大小，从一县城一路测到五百一十二县城，总共采集了七百多组数据。这不是随便跑个 bench every k 就 完事了的。这是一次严肃的工程级横屏 测试，用的是 csbench 十张表，每张一千万行，总数据量大约二十三个 g。 缓冲池分三档，二 g 数据远大于内存，得凭繁读磁盘。十二 g 热数据刚好放得下三二 g， 全部数据都能塞进内存。为什么要分这三档？因为缓冲池大小直接决定了性能瓶颈。在磁盘还是在锁，这一点非常关键，后面你就知道了。 先看最触目惊心的数据，三二 g 缓冲池加六十四线程，这是典型的云服务器配置。 maria d b 十二点一的 t p s， 只有 mysql 八点四的百分之七十二， 换乘一百二十八线乘，差距进一步拉大到百分之二十八点三。注意一个规律，缓冲时越大，差距越大。二 g 时差百分之十，七，十二 g 差百分之二十三，二 g 差百分之二十八。这个规律非常重要，它暗示了性能瓶颈，不再磁派 i o 而在内存中的锁。 这就是今天最反直觉的一个发现。通常我们觉得缓冲池越大，性能越好，因为更多数据滞留在内存里，减少了硬盘 i o。 但对 maria d b 来说，缓冲池越大，反而暴露出了更大的问题。 因为当所有数据都在内存里的时候，硬盘不再是瓶颈了，真正的瓶颈变成了谁能更快地拿到那把锁。 要理解 maria d b 为什么走上精简路线，得认识这个人， monty y denis mys q l。 的 亲爹，也是 maria d b 的 创始人。 orco 收购 mys q l 之后， monty 拉着团队 fork 出了 maria d b， 但他的技术哲学和 orco 团队截然不同。 monty 追求代码的简洁和可维护性，不喜欢 orco 那 套越做越复杂的路线。 于是那些 overco 加进去的并发症，被 maria d b 一个个精简掉了。 三个致命改动，我们逐个拆解。第一个，也是影响最大的一个 buffer pool 的 所力度， ysql 把缓冲池拆成了最多六十四个独立时历，每个时历有自己的 l r u 锁，六十四个县城可以同时扫描，不同时历互不干扰。 maria d b 呢？精简回了一个全局， mu t x 所有县城不管要访问哪个业，都得排队等同一把锁 来看代码。 ysql 这边，缓冲池是个数组，每个元素是一个独立的 buffer pool 时历，每个时历有自己的 l r u 锁， 六十四个县城可以同时操作，不同实力向高速公路的多条车道， maria d b 这边，所有县城共享同一把 miutax， 就是 只有一条车道的收费站，不管你有多少辆车，一次只能过一辆。 想象一下，六十四个县城同时发起请求，第一个县城拿到锁，开始扫描 l r u 链表，大约三毫秒，剩下六十三个县城全部堵塞。第二个等三毫秒，第三个等六毫秒，排到第六十四个，足足等了一百九十二毫秒。 而 mysql 那 边，八个实力，六十四个县城分成八组，每组八个县城最多等二十四毫秒，这就是八倍的差距。 第二个致命改动， alpha adaptive hash index 自适应哈希锁影。这是 eno d b 的 一个独门秘籍，当他发现某个锁影被频繁地作等值查找时，会在内存里自动建一个哈希表，下次查找直接 o 一 命中，不用再爬 b tree。 mysql 默认开启，还做了八路分区，避免锁争抢。 maria d b 呢，直接默认关了。 你可能会问， maria d b 为什么要关掉这么好的东西，因为它们的 offi 实现没有分区锁， 如果开启，在高病发下， offi 本身就会变成热点。所有县城都来查同一个哈希表所争抢又回来了，所以与其开了还添堵，不如干脆关掉。但代价就是所有等值查找都要走 b tree 的 log n 路径，比哈希的 o 一 慢了不止一个数量级。 第三个，致命改动，脏页刷盘的 page cleaner 县城。 eno d b 修改了内存中的数据页之后，需要在后台把脏页刷回此盘。 mysql 用四个县城并行刷，每个县城负责一部分 buffer pool 实力 maria d b 精简成了单县城。在写入密集的场景下，这个单县城 cleaner 根本忙不过来，脏页堆积导致新的写入被迫等待，这就是所谓的 checkpoint store。 看代码就很直观， mysql 创建四个可疑那儿县城，分别处理不同的 buffer pool， 实力互不阻塞。 maria d b 只有一个县城要扫完所有脏页，在读多写少的场景下还凑合，但一旦写入量上来，单县城可疑那儿就成了整个系统的短板。脏页来不及刷， buffer pool 里全是脏页，新写入没地方放，只能原地等。 三个改动叠加在一起，效果是乘法而不是加法。全区所让所有县城排队， offi 关闭，让每次查找都变慢，单县城可以哪儿让脏液堆积？三重 debuff 叠满六十四县城以上的场景直接崩盘。 说到 mys ql 这边的并发症，不得不提 sony bimes， 他 是 oracle 团队中 inno d b 的 核心开发者， bufferpool 的 new text 拆分和 page twinner 的 多线成化都是他主导的。 正是这些年持续的并发症积累，让 mys ql 在 六十四县城以上的场景中越来越强，而 maria d b 把这些优化一个个拿掉，差距自然越来越大。 用一条 insert 的 生命周期来感受差距。同一条插入语句， my s q l 走分段所加 offi 快 速命中，零点八毫秒搞定。 maria d b 呢？ 光等全局 mutax 就 花了三点三毫秒，再加上没有 offi， 要走 b tree 便利，总共五点一毫秒。一条语句慢六倍，累积到每秒数千条的吞吐量，差距就是百分之二十八。 回到超市的类比， mysql 超市有八条独立收银台，每条台前最多排八个人。 maria d b 超市只有一条收银台，所有人排一条队，当顾客只有几个人的时候，差别不大， 但促销日涌进来六十四个顾客。 mysql 这边分八条队，每人等三分钟， maria d b 那 边排一条长龙，排到最后的人得等半个小时。数据不会说谎，七百组数据点都在说同一件事。 还有一个更诡异的发现， maria d b 十二点一，在五百一十二限程加三二 g 缓冲池的只读测试中， t p s。 居然比二百五十六限程时还低了百分之十五。 加现成不仅没变快，反而变慢了。这就是所谓的反向扩展，所争抢已经严重到了一个临界点，额外的现成带来的全部是开销，而不是吞吐。 mysql 那 边完全没有这个问题，五百一十二现成的 tps 依然在稳固上升。 顺便说一下， mysql 九点六，它比八点四在高并发下又提升了五到十个百分点，主要来自 group commit 和 redo log 并行写入的优化。在六十四县城以下，二者几乎持平。如果你的业务并发不高，八点四作为 lts 版本是更稳妥的选择。 但如果是一百二十八县城以上的高病发场景，九点六确实更强。现在来理解那个反直觉的规律，为什么缓冲池越大， maria d b 越吃亏？ 当缓冲池只有二 g 时，大量请求要等磁盘 i o， 这时候所增强反而被 i o 等待掩盖了，差距只有百分之十七。当缓冲池涨到三二 g， 所有数据都在内存里，磁盘完全不是瓶颈了，性能天花板完全有所的效率决定 ysql 的 分段锁方案，这时候优势尽显，差距直接拉到百分之二十八。 但话说回来， maria d b 团队的选择并非完全没道理，代码复杂度降了百分之三十，维护成本低了，出 bug 容易，定位在单线城和低病发场景下，性能也没损失。但问题是云原生时代六十四和一百二十八核的实力已经是常态了， 你的代码再简洁，跑不过人家，用户最终还是会用脚投票。 如果你现在用的是 maria db， 也不用慌，短期有几个优化方向，第一，用连接池限制实际病发限程在十六到三十二之间，避开所争抢的爆发区。第二，尽量给大缓冲持，虽然所竞争还在，但至少减少了 l r u 扫描的频率。 第三，降低 l r u 扫描深度，缩短每次持索时间。第四，毒血分离，把毒请求打散到从库上。 长期来看，如果你在做新项目的技术选型高并发症场景，建议直接选 mysql 八点四或九点六。如果已经在用 maria d b， 可以 关注下 percona server， 它是 mysql 的 增强版，保留了所有并发症优化，还加了额外的监控能力。 另外，一定要关注 maria d b 十三 x 的 路线图，看它们会不会把 multi instance buffer pool 加回来。 最后列出关键参数的默认值对比，你可以截图保存。注意， maria d b 那 边有两个参数写的是不可调， buffer pool instances 和 page cleaners。 这两个不是配置问题，是代码层面直接写死的，想调都没得调，除非改原码自己编辑。 来回顾今天的核心要点， maria d b 十二点一、性能暴跌的根源是三个，致命，精简全局 miutex 替代分断锁、 r t 默认关闭 page cleaner 单线成化， 三重 debuff 叠加，在高并发症加大缓冲池的场景下，效果最为致命。七百组数据不会说谎，技术选型永远要看你的发病度在哪个区间。 ysql 和 maria d b 的 分歧，本质上是两种技术哲学的碰撞，追求极致性能，还是追求代码简洁？ monty 的 理想很美好，但在芸芸生时代，六十四和一百二十八核的服务器已经是标配，高并发才是主战场。 这份七百组数据的报告就是最诚实的裁判。如果觉得有收获，欢迎一箭三连，我们下期见！

昨天直播的时候有个兄弟在问 merry d b 六百二十 g 数据导入，买四个五点七，有什么好的解决方案吗？六百多个 g， 这个数据量其实也不算大，如果用逻辑导入导出的方式，估计需要几十个小时，而且后续的数据还不太好同步过去， 需要的停机窗口的时间比较大。用这种方法最好是用多线程方式，性能会好一些。嗯，最好是用专门的同步工具，比如 dts 之类的工具，性能也还可以，后续的数据也能同步过去，想切换的话随时都能切换，对业务的影响小，缺点就是需要花钱。

也简单学习了一下高斯 dp 否买车口的数据库的特点，那我们这一小节来看一下他的分布式特点啊，首先呢，那高斯 db 否买车口呢，进行计算存储的一种结构，那他将他的这个计算节点呢，我们叫做 secono 的啊， 然后他的存储节点呢，叫 sorry no 的啊，那 secono 的上呢，主要做一些事物的支撑啊，以及我们八个破，对吧？然后 soco 的一个解析啊，那存储节点上呢，我们主要是做了一些啊，日制的血压对吧，日制的回放啊， 日啊夜的管理对吧？还有以及比如说啊日日志的复制啊等等啊，就是有关于 io 方面的，我们去下放到我们对应的一个存储段啊， 这就我们的计算与存储的结构。那其次呢，他却产生了一个叫做存储偷向层 s a l 这么一个特点，那首先呢， s l 他是一个逻辑层，他并不是一个物理存在的啊。然后其次呢，他是将这个对应的一个 数据存储跟收口前端的事物查询啊，这些进行了一个隔离，也就说我上层呢，只支持去做一些这个前端的收购的一个前端啊，一些解析啊，对吧？事物的接收啊分发，然后后段呢去做一个数据的处理。 那第三点呢，就是说我们的售后节点上执行的这种日制啊，跟存储时间执行的日制呢，他都是在这个 s slides 节点组成的啊，也就是说在他的存 数节点组成啊。那第四点呢，就是说，呃，他的这个 s a l 层呢，将这个数据页呢去做了一次分割，分割成这么一些 sid 啊 啊， space id， 配置 id 进行划分，然后将它去划分成对应的一些分片啊，那第四点呢，就是它的横向扩展啊，也就说如果我出现了这种资源的危机，或者这个存储节点的危机啊， 说存储的危机，我可以进行横向的扩展，有网上去堆一些对应的一些存储啊，那最后一个特点呢，就是说他的这个数据本地化， 能够去做一些这个啊，存储在对应的存储节点上，然后通过斯莱斯进行一个服务。那我们可以看到这里简单的看一下，他在这个存储抽象层呢，是放到 div 这个节点 上的，那他将这个存储去划分成不同的一个页的一个啊，我们说的 slides， 也就是我切片啊， 那从这张图上呢，我们可以看到，当数据进行下发写的请求的时候呢，那他是可以通过写结点啊，我们也就说的主节点进行一个写的请求的承接，然后将数据进行一个下 下发啊，到我们的对应的存储上，存储上呢？如果进行赌请求呢，是可以通过 n 个啊，这最多最多到十五个节点的制度节点啊，能够将数据进行一个向上 提供支撑，查询使用啊。那其次呢，他们也会去在只读节省啊，进行一些啊，纬度日制的一个回放啊，模拟出主节点上的这个内存中的一些信息啊。 好的，那我们这里简单的说了一下，我们这个高斯蒂皮佛买车口分不是存储的一个特点啊，下一小节我们再见。