简介：MariaDB 10.5.11 Linux x86_64 安装包，面向需要在 Linux 服务器上部署或升级 MariaDB 的数据库管理员、运维人员及开发测试者，用于搭建高性能、高可用数据库环境。压缩包大小 347.07MB，包含 MariaDB 10.5.11 在 x86_64 平台上的完整二进制安装文件；文件总数与类型明细无有效数据，因此不做展开。此版本在存储引擎、SQL 兼容性、GTID 复制、线程池、查询优化与安全审计等方面均有改进，支持 InnoDB、Aria、ColumnStore 等引擎；其中 InnoDB 支持事务处理，MyISAM 适合快速读取，Aria 侧重快速崩溃恢复，XtraDB 为增强型 InnoDB，用户可根据业务场景灵活选择，同时也可利用虚拟列、多源复制、半同步复制等特性处理复杂查询与大规模并发访问。已有291人学习下载，便于完成数据库初始化、配置与上线使用，也可为主从复制、性能调优、安全加固等实践提供直接软件基础。
1. MariaDB 10.5.11 的 Linux 二进制包：为什么我还要手动装它
在绝大多数 Linux 主机上，用自带源装 MySQL 或 MariaDB 是默认选择，但总有限制环境逼你换思路：某内网服务器既连不上公共镜像站，又不允许用 yum 往生产机器上装东西；或者你需要在同一台机器上跑两个不同版本的数据库，而包管理器只提供一个固定版本。这时候，直接拿一份 MariaDB 10.5.11-linux-x86_64.tar.gz 丢到服务器上解压、初始化、启动，反而最可控。这份二进制包是官方预编译产物，不依赖目标机的编译器，基础内核是 glibc 2.17 以上就能跑。它解决的不仅是“能不能装”，而是“装在哪个目录、用什么参数、怎么独立管理”都能自己说了算。适合不想被系统源绑架、又需要快速复现一套数据库环境的同行。
2. 安装前准备：版本选型、依赖检查与目录规划
2.1 为什么选 10.5 而不是 10.4 或 10.6：特性与兼容性平衡
MariaDB 10.5 在官方长期支持系列里属于一个相对稳妥的折中。它继承了 10.4 里已经洗过的 InnoDB 参数默认值，又比 10.6 多了点保守气质——10.6 在窗口函数和 CTE 上改动更大，有些旧应用里的 SQL 写法到 10.6 的优化器下执行计划会变，提前翻车也常见。10.5 的 InnoDB 支持部分在线 DDL，临时表引擎默认改成内存中的临时表结构，整体性能比 10.3/10.4 更可预期。
另外一点，10.5.x 系列在 x86_64 上的 glibc 兼容面比较广，你在 CentOS 7、Ubuntu 18.04 或者更老的内核环境里都能解压跑起来。10.6 以后编译参数对新内核特性依赖更多，老系统上反而容易出现“初始化成功但启动即崩溃”的玄学问题。如果是新部署且没有历史包袱，选 10.5.11 这个具体版本的二进制包，踩坑资料也多，网上搜得到的问题基本都能覆盖到。
2.2 检查依赖：libaio、ncurses 与 glibc 缺一不可
二进制包不是纯静态编译，它动态链接了一部分系统库。最常见的问题是缺 libaio。InnoDB 在初始化数据目录和启动时都会调io_setup，缺少 libaio.so.1 会直接导致mysqld: error while loading shared libraries报错。可以先查一遍：
ldd mariadb-10.5.11-linux-x86_64/bin/mysqld | grep "not found"这条命令会把所有动态库缺失情况列出来。如果缺 libaio，用系统的包管理器装，CentOS 系执行yum install libaio -y，Ubuntu 系执行apt install libaio1 -y。注意 64 位环境别漏了libaio.so.1的软链，有些精简容器镜像里只有libaio.so没有带版本号的那个文件，手动建一个软链也能解决。
ncurses 库一般在mysql_upgrade和mysqld_safe里会被调用，但实际缺的少。另外检查libstdc++是否在 6.0 以上，10.5 的二进制用到了 C++11 的 ABI，老版本 libstdc++.so.5 跑不起来。这块用上面的ldd基本一眼能看出来。
2.3 目录规划与用户创建：用独立用户跑数据库更稳
解压之前先决定三件事：安装目录放哪、数据目录放哪、谁来启动进程。我习惯把二进制放在/opt/mariadb-10.5.11，数据目录独立放在/opt/mariadb-data，socket 文件放在/opt/mariadb-run。这样升级时只动安装目录，数据目录不受影响，备份也只盯数据目录。
创建专用系统用户，一般叫mysql或mariadb，避免用 root 跑数据库。虽然二进制包的脚本里有--user=root的选项，但 root 跑 mysqld 风险太大，一旦 SQL 注入拿到文件权限就是灾难。创建用户和目录：
groupadd mariadb useradd -g mariadb -s /sbin/nologin mariadb mkdir -p /opt/mariadb-10.5.11 /opt/mariadb-data /opt/mariadb-run chown -R mariadb:mariadb /opt/mariadb-10.5.11 /opt/mariadb-data /opt/mariadb-run这里-s /sbin/nologin让该用户不能登录 shell，只用于服务运行。目录属主必须给到mariadb，否则后面初始化时写数据目录会提示Permission denied。注意/opt/mariadb-run权限不能是 777，否则会让普通用户往里面塞文件，被利用来做符号链接攻击。
3. 解压、初始化与启动：三个命令把实例跑起来
3.1 校验文件完整性：sha256 与 md5 不是玄学
从网上下载的 tar.gz 包，第一件事不是解压，是校验。官方一般会提供sha256sum校验值。原始文件名里没有校验和，需要你从发布页拿到对应的.sha256sum文件，或直接核对发布页给出的哈希。常见做法是：
echo "目标哈希值 mariadb-10.5.11-linux-x86_64.tar.gz" | sha256sum -c - --quiet sha256sum mariadb-10.5.11-linux-x86_64.tar.gz-c -表示从标准输入读取校验文件内容，--quiet让匹配成功时不输出额外信息。输出mariadb-10.5.11-linux-x86_64.tar.gz: OK说明完整；如果无输出或显示 FAILED，别继续，重下吧。这一步不费事，但能拦掉 99% 的“解压后发现少了文件”或“被中间人替换”的坑。
3.2 解压迁移与目录权限：文件属主必须改
解压时注意保留文件权限，tar 包里的目录结构是预设好的，用-xzf解压即可。不建议直接在/root下解压再 mv，因为 mv 会保留原属主，如果原属主是 root，后面启动就会因为无法读写数据目录而失败。我的做法是：
cd /opt tar -xzf /tmp/mariadb-10.5.11-linux-x86_64.tar.gz -C /opt mv /opt/mariadb-10.5.11-linux-x86_64 /opt/mariadb-10.5.11 chown -R mariadb:mariadb /opt/mariadb-10.5.11移动后必须重设属主。有些人在 mv 后省略chown，直接用 root 开始初始化，之后用--user=mariadb启动时，数据目录里生成的ibdata1等文件还是 root 属主，于是 mysqld 只能报权限错退出。这个问题发生频率极高，先改了省事。
3.3 初始化数据目录：scripts/mysql_install_db 的正确姿势
10.5 的二进制包内置了scripts/mysql_install_db，它是基于--initialize的封装。初始化命令要明确指定数据目录和用户：
cd /opt/mariadb-10.5.11 scripts/mysql_install_db --user=mariadb --datadir=/opt/mariadb-data \ --basedir=/opt/mariadb-10.5.11 --auth-root-authentication-method=normal--datadir指向刚才建好的数据目录，不是安装目录，别搞反。--basedir指向二进制包解压目录。--auth-root-authentication-method=normal让 root 用户使用常规密码认证，否则默认用unix_socket认证，你会发现自己用 mysql 客户端连 root 时永远需要先切到系统 mariadb 用户。
初始化过程中会往--datadir写入系统表、ibdata1、undo日志和默认的mysql库。初始化完成后，/opt/mariadb-data下会多出一批文件，属主已经是mariadb。如果中途报FATAL ERROR: Could not find ./bin/my_print_defaults，说明--basedir指错了路径，因为初始化脚本会基于 basedir 找辅助工具。
3.4 启动 mysqld_safe 与登录验证：默认 root 怎么进
初始化完成后，先别急着配 systemd，直接手动启动一次，看能不能跑起来：
/opt/mariadb-10.5.11/bin/mysqld_safe \ --user=mariadb --datadir=/opt/mariadb-data \ --socket=/opt/mariadb-run/mysql.sock --port=3306 &mysqld_safe是守护外壳，mysqld 崩了它会自动拉起。--socket一定要显式指定，因为默认它会在/var/lib/mysql/mysql.sock或编译时的默认路径，而你数据目录不在那。端口不写也行，默认 3306，但多实例部署时端口是区分品。启动后等两三秒，用mysqladmin ping探活：
/opt/mariadb-10.5.11/bin/mysqladmin --socket=/opt/mariadb-run/mysql.sock -u root ping如果返回mysqld is alive，说明服务正常。此时 root 密码是空，但你用的是 socket 连接，且 root 只允许本机登录。用mysql -u root进去后第一件事设密码：
ALTER USER 'root'@'localhost' IDENTIFIED BY '你的强密码'; FLUSH PRIVILEGES;注意 10.5 里已经不支持SET PASSWORD旧语法，建议统一用ALTER USER。
4. 参数调优与基础配置：my.cnf 里值得调的七个关键项
4.1 数据目录、socket 与 pid：路径统一才能少踩坑
启动成功后，要把参数固化到配置文件里，不能每次启动都靠命令行拼。默认配置路径有几个候选，/etc/my.cnf、/etc/mysql/my.cnf、$basedir/my.cnf，mysqld 启动时会按先后顺序读取。我用固定一套：
[mysqld] basedir=/opt/mariadb-10.5.11 datadir=/opt/mariadb-data socket=/opt/mariadb-run/mysql.sock pid-file=/opt/mariadb-run/mysqld.pid port=3306配置好后，无论用mysqld_safe还是 systemd，都不需要再传路径参数。如果有多个实例，port和socket必须不同，且 pid 文件也要区分。socket 路径如果和客户端默认路径不一致，客户端连接时要么--socket指定，要么配置[client]节：
[client] socket=/opt/mariadb-run/mysql.sock否则你会碰到“服务器明明启动了，但mysql命令连不上”的幻觉错误，后面避坑章节细说。
4.2 InnoDB 缓冲池与日志：内存多大决定性能起点
10.5 的 InnoDB 缓冲池默认是 128MB，对生产实例通常不够。设置缓冲池大小的原则是：如果机器内存只有 4GB，就设 1GB；8GB 内存可以给到 2～3GB。别把整个内存都塞给数据库，系统本身和查询排序也要留余量。日志文件大小innodb_log_file_size默认是 96MB，写入压力大的应用建议调到 256MB 或 512MB。
innodb_buffer_pool_size=2G innodb_log_file_size=256M innodb_flush_log_at_trx_commit=1 innodb_file_per_table=ONinnodb_flush_log_at_trx_commit=1：每次事务提交都刷盘，保证不丢数据，适合数据库应用；如果对一致性要求不高、追求吞吐，可以改成 2，但掉电可能丢最近一秒的事务。innodb_file_per_table=ON：每张表一个独立表空间，drop 表时直接删文件，回收磁盘空间方便，10.5 默认已经是 ON，但显式写出来能防哪些my.cnf是否被覆盖。
4.3 binlog 与慢查询：开审计前先想清楚代价
binlog 是主从复制和时间点恢复的基础，但开了 binlog 会带来写入开销。如果不需要复制，且备份走全量快照，可以不开。需要开的消费者，先确定格式：
server-id=1 log-bin=/opt/mariadb-binlog/mysql-bin binlog_format=ROW expire_logs_days=7 max_binlog_size=256Mserver-id在单机可以设 1，多实例必须唯一。log-bin路径最好独立目录，别和数据目录混在一起。binlog_format=ROW在 10.5 是默认值，比 statement 更安全，不会因为 SQL 里用NOW()导致主从数据不一致。expire_logs_days建议设 7，太久会撑爆磁盘，日志清理脚本往往依赖这个参数，10.5 以后的参数名变成了binlog_expire_logs_seconds，以秒为单位，两套都写上能兼容老客户端。
慢查询日志平时可以关闭，排查问题时再开，避免额外 IO。我一般只在性能调优期间临时开：
slow_query_log=OFF long_query_time=24.4 字符集与排序规则：utf8mb4 统一天下
10.5 默认字符集是utf8mb4，但为了保险，还是显式写清楚：
character-set-server=utf8mb4 collation-server=utf8mb4_general_ci skip-character-set-client-handshakeskip-character-set-client-handshake会忽略客户端声明的字符集，强制走服务端设置，否则某些老 JDBC 驱动会在连接时把自己的latin1声名传给服务端，导致新写入的中文乱码。排序规则用general_ci还是unicode_ci看业务要求，general_ci速度快，unicode_ci排序更符合 Unicode 规范，国内业务用前者足够。
5. 避坑与排查：二进制包部署最常见的六个翻车现场
5.1 初始化时报缺少 libaio.so.1
现象：执行scripts/mysql_install_db时，报error while loading shared libraries: libaio.so.1: cannot open shared object file。
原因：系统没有安装 libaio 或者只有 libaio.so 没有带版本号的软链。mysqld 初始化时调用了io_setup系统调用，这个调用由 libaio 提供，缺了就直接跑不起来。
解决：CentOS/RHEL 系使用yum install -y libaio，Debian/Ubuntu 系使用apt install -y libaio1。装完用ldd bin/mysqld | grep libaio确认能解析到/usr/lib64/libaio.so.1或/usr/lib/x86_64-linux-gnu/libaio.so.1。如果装完还找不到，可以查一下/sbin/ldconfig -p | grep libaio，手动建立ln -s /usr/lib64/libaio.so /usr/lib64/libaio.so.1。这个坑在精简版 Docker 容器里尤其常见。
5.2 mysql_install_db 提示该脚本已弃用
现象：10.5 的scripts/mysql_install_db输出mysql_install_db is deprecated. Please consider switching to mysqld --initialize。
原因：这不是报错，是提示。MariaDB 官方从 10.4 左右就开始推荐用mysqld --initialize或mariadb-install-db，老的 mysql_install_db 是 MySQL 5.7 时代的产物。
解决：如果你更想用新方式，直接执行：
/opt/mariadb-10.5.11/bin/mysqld --initialize --user=mariadb --datadir=/opt/mariadb-data注意--initialize不会像老脚本那样把 root 密码留空，而是生成一段临时密码写在 stdout 里。启动后mysql -u root -p输入该临时密码，登录后再ALTER USER改密。实际使用中，老脚本也能完成初始化，只是会有弃用提示。如果不想每次都看到，改用mariadb-install-db，10.5 包里提供了这个软链。
5.3 启动时提示 datadir 不存在或权限错误
现象：mysqld_safe 启动后立刻退出，日志里出现[ERROR] Can't find error-message file或[ERROR] Could not open required defaults file，更常见的是Permission denied指向/opt/mariadb-data。
原因：数据目录是 root 创建的，或者初始化时用了 root 用户，导致目录属主不是 mariadb。mysqld 切换到--user=mariadb后无法写目录。
解决：检查目录属主：
ls -ld /opt/mariadb-data /opt/mariadb-10.5.11如果属主是 root，执行chown -R mariadb:mariadb重设。还有一个隐性原因：父目录/opt权限如果是 755，没给mariadb写权限，但子目录属主正确也不受影响；真正要命的是 SELinux 开启状态下，mysqld 对自定义目录的上下文不对。解决方法是暂时用setenforce 0验证，如果是 SELinux 导致，再为自定义目录打上下文标签chcon -R -t mysqld_db_t /opt/mariadb-data。我一般直接关掉 SELinux 或设置为 permissive，生产环境谨慎对待。
5.4 socket 连不上：/tmp/mysql.sock 与 /opt/mariadb-run/mysql.sock 之争
现象：执行mysql -u root -p后报ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'，但明明看到 mysqld 进程活着。
原因：客户端默认找/tmp/mysql.sock，但你在配置里指定了/opt/mariadb-run/mysql.sock。两边路径不一致，客户端自然找不到。如果你只改了服务端配置文件，没改客户端配置，就会出现这个经典幻觉。
解决：两种办法，任选其一。一是给客户端加绝对路径：
mysql --socket=/opt/mariadb-run/mysql.sock -u root -p二是写进配置文件的[client]节，如上章所说。我更推荐后者，因为以后所有本地命令行工具都会自动用对 socket，包括mysqldump。注意mysqladmin ping也一样要指定 socket，否则也会误判数据库死掉。
5.5 忘记 mysql_upgrade：跨小版本后权限表报错
现象：从旧版本数据目录直接换到 10.5.11 二进制包，启动正常，但执行查询时报Table 'mysql.proc' doesn't exist或Unknown column 'Password' in 'mysql.user'。
原因：10.5 的 mysql 系统库结构和旧版本可能不同，比如mysql.user表中的认证插件字段变了，老数据目录里的系统表没有升级。单纯替换二进制不会自动迁移系统库。
解决：启动新版后，别急着用业务，先跑升级工具：
/opt/mariadb-10.5.11/bin/mysql_upgrade \ --socket=/opt/mariadb-run/mysql.sock -u root -p它会扫描所有库表，比对版本，并修正系统表和已损坏的旧表。注意在升级前先备份数据目录。这个工具在 10.5 里还会执行CHECK TABLE，如果检查到旧表引擎不支持，会提示你转换。如果平时是停机升级，建议跑完后重启一次实例，让新参数全面生效。
5.6 systemd 接管后卡在启动超时
现象：手写 systemd service 文件之后，systemctl start mariadb一直卡在activating，等 90 秒后超时失败，但手动跑mysqld_safe却正常。
原因：systemd 的 Type 没有设置对。mysqld_safe 会 fork 出 mysqld 进程，systemd 默认认为主进程退出服务就结束，而 mysqld_safe 作为守护壳不会退出，导致 systemd 以为启动失败。另一个原因是TimeoutStartSec设置太短，大内存实例初始化缓冲池耗时就超过默认 90 秒。
解决：service 文件里用Type=forking配合PIDFile指向 pid 文件路径：
[Service] Type=forking User=mariadb Group=mariadb ExecStart=/opt/mariadb-10.5.11/bin/mysqld_safe --defaults-file=/etc/my.cnf ExecStop=/opt/mariadb-10.5.11/bin/mysqladmin shutdown --socket=/opt/mariadb-run/mysql.sock PIDFile=/opt/mariadb-run/mysqld.pid TimeoutStartSec=180mysqld_safe启动时会把 mysqld 的 pid 写到配置指定路径，systemd 靠这个 pid 判断服务是否拉起。我试过不用Type=forking，改用Type=simple直接跑mysqld，也可以，但日志输出会直接打到 stdout，需要自己处理重定向。从稳定性来说，forking模式兼容性最好。
6. 验证安装与后续维护：从版本号到日常备份的收尾动作
6.1 用 mysqladmin ping 与 status 确认实例健康
安装完成后，建议做一次完整的状态验证，不要只看到进程存在就认为万事大吉。执行：
/opt/mariadb-10.5.11/bin/mysqladmin --socket=/opt/mariadb-run/mysql.sock -u root -p ping /opt/mariadb-10.5.11/bin/mysqladmin --socket=/opt/mariadb-run/mysql.sock -u root -p statusping返回mysqld is alive只说明连接有效，status会给你 uptime、线程数、查询数、每秒流量等关键指标。我还会顺手查一下版本和关键参数是否真正生效：
SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW VARIABLES LIKE 'character_set_server';这里有个坑：SHOW VARIABLES显示的参数值可能和你配置文件写的不同，如果配置里写错了节名，mysqld 会静默忽略。务必确认输出值，别只看文件里写了什么。
6.2 配置 systemd 服务：让数据库跟开机自启
手动启动只是临时验证，生产环境必须由 systemd 管理。将上述 service 文件置于/etc/systemd/system/mariadb.service，然后执行：
systemctl daemon-reload systemctl enable mariadb systemctl start mariadb systemctl status mariadb --no-pager注意enable是创建开机软链，start是立即启动。如果status显示Active: active (running)，说明接入成功。有一个细节：ExecStart里如果不写--defaults-file，systemd 环境下 mysqld_safe 会按默认顺序找配置文件，可能找到/etc/my.cnf而不是你放在别处的配置。我习惯在 service 文件里显式指定--defaults-file=/etc/my.cnf，避免默认搜索顺序造成的意外。
6.3 备份恢复演练：xtrabackup 与 mysqldump 的取舍
收尾阶段最后一步，也是我每次部署都要强制执行的一步：备份和恢复演练。只用 mysqldump 是不够的，它备份逻辑数据，对大数据量恢复太慢。常见做法是冷备或物理备份，10.5 官方支持mariadb-backup，它是 xtrabackup 的分支。做一次全量备份：
/opt/mariadb-10.5.11/bin/mariadb-backup \ --backup --target-dir=/opt/backup/full \ --user=backup_user --password=****恢复时先准备全量备份：
/opt/mariadb-10.5.11/bin/mariadb-backup --prepare --target-dir=/opt/backup/full /opt/mariadb-10.5.11/bin/mariadb-backup --copy-back --target-dir=/opt/backup/full--prepare会把备份文件中的未提交事务回滚，让数据文件达到一致性状态；--copy-back才把数据写回数据目录。这一步极容易漏，很多人直接 copy 备份文件到 datadir 然后启动，结果 InnoDB 崩溃恢复时报错。
从那以后，我每次部署完都会强迫自己完整走一遍“备份 → 清空数据目录 → 恢复 → 启动 → 查询数据”循环，确认备份不是只能写在脚本里的摆设。很多事故都是备份存在但恢复不了，赶上一次就够刻骨铭心了。希望这篇笔记能帮你把二进制包这条路走顺，省下来的那几小时，留着好好休息。
本文还有配套的精品资源，点击获取
