简介：本资源是郑州大学计算机与人工智能学院《数据库系统原理》课程的全套实验报告，面向高校数据库初学者及实践教学需求者，聚焦DBMS系统认知、国产数据库GreatSQL部署与运维、实验过程记录与结果分析等核心能力培养。报告覆盖9个递进式实验，涵盖CentOS 7虚拟机环境配置（含SELinux/防火墙关闭原理与命令）、依赖包安装、GreatSQL二进制部署与systemd服务管理、逻辑/物理组件实操（基本表、视图、触发器等），并严格遵循课程对截图编号、图题标注、表格格式及书面行文规范的要求。资源为1个3.69MB的docx文档，结构完整、内容详实，含实验目的、步骤、问题反思与性能安全讨论，可直接用于课程提交或作为数据库实践操作范本参考。目前已有511人学习下载，是理解商用数据库底层管理与实验报告规范化撰写的优质教学材料。
1. GreatSQL 8.0.32 安装不是“解压+启动”就完事：CentOS 7 上关 SELinux 和 firewalld 是硬门槛，跳过直接翻车
你是不是也试过：下载好 GreatSQL 二进制包，tar xf 解压，systemctl start greatsql —— 然后systemctl status greatsql显示 active (exited) 或 failed，ps -ef | grep mysqld一片空白，ss -lntp | grep 3306什么也看不到？别急着重装，这大概率不是 GreatSQL 的锅，而是 CentOS 7 默认开启的 SELinux 和 firewalld 在“静默拦截”。郑州大学计算机与人工智能学院这门《数据库系统原理》实验课，第一关就卡在这儿——它不考你会不会写 SQL，专考你敢不敢动系统底层策略。很多同学按文档一路敲命令，到启动那步突然卡死，回头翻日志/var/log/messages或journalctl -u greatsql -n 50，满屏Permission denied、Operation not permitted，才意识到：原来数据库不是跑在“用户空间”，而是卡在“内核策略”里。这套环境面向的是刚接触 Linux 的本科生，但部署逻辑却和生产环境一致：必须先让系统“松绑”，再让服务“扎根”。所以本文不讲抽象架构，只聚焦一个目标：在 VMware 虚拟机里的 CentOS 7 环境下，把 GreatSQL 8.0.32-25 这个特定版本，从零装成能连、能查、能建库的可用状态。所有命令、路径、配置项，全部来自实验报告原始操作记录，不加脑补，不套模板，错一步就告诉你为什么错、怎么看日志、怎么救回来。
2. 环境准备与依赖安装：CentOS 7 基础加固反而成了 DBMS 的绊脚石
GreatSQL 虽然是 MySQL 兼容分支，但它对底层系统的要求比社区版更“较真”。尤其在 CentOS 7 这类默认启用强制访问控制（MAC）的发行版上，不提前清理环境，后续所有操作都是玄学。下面这三步不是可选项，是启动前的“安检流程”。
2.1 关闭 SELinux：不是“不安全”，而是避免策略冲突导致 mysqld 启动失败
SELinux 的enforcing模式会严格限制进程对文件、端口、IPC 资源的访问。而 mysqld 进程需要读写/var/lib/mysql/、监听3306端口、创建 Unix socket 文件、调用setrlimit设置资源上限——这些动作在默认策略下极大概率被拒绝。
提示：实验报告中
setenforce=0是笔误，正确命令是setenforce 0（注意空格，无等号）。这个命令只是临时切换为 permissive 模式，重启后失效；要永久关闭，必须修改配置文件。
# 临时禁用（立即生效，重启失效） sudo setenforce 0 # 永久禁用（修改配置文件，重启后仍生效） sudo sed -i '/^SELINUX=/c\SELINUX=disabled' /etc/selinux/config # 验证是否已设为 disabled（输出应为 disabled） sudo sestatus | grep "current mode"参数说明：
setenforce 0：将当前运行模式设为 permissive（仅记录拒绝日志，不实际拦截）；setenforce 1才是 enforcing 模式。sed -i命令直接编辑/etc/selinux/config，把SELINUX=enforcing或SELINUX=permissive替换为SELINUX=disabled。这是唯一能让 SELinux 彻底退出的配置。sestatus是 SELinux 状态检查工具，current mode行确认当前策略是否已落地。
为什么不能只用setenforce 0？因为 GreatSQL 的 systemd 服务在开机时会自动拉起 mysqld，而此时系统尚未执行setenforce 0，mysqld 已被 SELinux 拦截并退出，systemd 记录为failed，后续再手动setenforce 0也救不活——必须从根上禁用。
2.2 停用 firewalld：不是“放弃防护”，而是防止端口通信被静默丢弃
firewalld 默认放行的端口极少，3306（MySQL 默认端口）不在白名单内。即使 mysqld 成功启动并监听了0.0.0.0:3306，外部客户端（包括本机mysql -h127.0.0.1 -P3306）发起 TCP 连接时，数据包会在内核 netfilter 层被 DROP，连接超时，ss -lntp却能看到监听状态——这种“看得见连不上”的问题最折磨人。
# 停止 firewalld 服务（立即生效） sudo systemctl stop firewalld # 禁用开机自启（永久生效） sudo systemctl disable firewalld # 验证状态（应显示 inactive (dead)） sudo systemctl is-active firewalld逻辑说明：
systemctl stop是运行时停止，不影响配置；systemctl disable是移除开机启动项，二者缺一不可。- 实验环境是 VMware 虚拟机内部闭环网络，无外网暴露风险，停用防火墙是合理取舍。生产环境则需用
firewall-cmd --add-port=3306/tcp --permanent && firewall-cmd --reload精准放行。
2.3 安装核心依赖包：GreatSQL 8.0.32 对 glibc 和动态库有硬性要求
GreatSQL 8.0.32-25-Linux-glibc2.17-x86_64-minimal 这个包名已经说明一切：它编译时链接的是 glibc 2.17，且依赖libaio（异步 I/O）、numactl（NUMA 内存管理）、jemalloc（内存分配器）等关键库。CentOS 7 默认最小化安装往往缺失这些，导致 mysqld 启动时报error while loading shared libraries。
# 一次性安装全部必需依赖（实验报告所列完整清单） sudo yum install -y \ pkg-config \ perl \ libaio-devel \ numactl-devel numactl-libs \ net-tools \ openssl openssl-devel \ jemalloc jemalloc-devel \ perl-Data-Dumper \ perl-Digest-MD5 \ python2 \ perl-JSON \ perl-Test-Simple参数说明与常见误区：
libaio-devel提供头文件和静态库，libaio（运行时库）通常已预装，但显式安装更稳妥；numactl-devel和numactl-libs必须同时装，否则 GreatSQL 初始化时会报libnuma.so.1: cannot open shared object file；perl-JSON是 GreatSQL 内部某些管理脚本（如greatsql_install_db.pl）的依赖，缺失会导致初始化失败；python2是 CentOS 7 默认 Python，GreatSQL 的部分工具链（如mysql_config_editor）仍依赖它，不要强行替换成 Python 3。
注意：若执行
yum install报No package xxx found，请先运行sudo yum update -y并确认仓库源可用（sudo yum repolist）。CentOS 7 EOL 后，建议替换为阿里云或清华源（sudo sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Base.repo && sudo sed -i 's|#baseurl=http://mirror.centos.org|baseurl=https://mirrors.aliyun.com|g' /etc/yum.repos.d/CentOS-Base.repo）。
3. GreatSQL 8.0.32-25 二进制部署：解压 ≠ 安装，目录权限和用户隔离是关键
GreatSQL 官方提供的是“免编译二进制分发包”，没有传统./configure && make && make install流程，但“免编译”不等于“免配置”。从解压到 systemd 服务注册，每一步都涉及路径、权限、用户上下文的精确控制。实验报告里cd /usr/local && wget ...是标准做法，但背后有三处极易出错的细节。
3.1 下载与解压：选择 minimal 包，避免冗余组件干扰初学者理解
GreatSQL 官网提供多个构建版本：full（含调试符号、测试套件）、debug（带调试信息）、minimal（仅运行时必需文件）。实验明确指定GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal.tar.xz，这是最优选——体积小（约 280MB）、启动快、无多余进程干扰，适合教学环境快速验证。
# 创建统一安装根目录（符合 Linux FHS 标准） sudo mkdir -p /usr/local # 进入目录并下载（使用实验报告指定 URL） cd /usr/local sudo wget https://product.greatdb.com/GreatSQL-8.0.32-25/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal.tar.xz # 解压（-x: extract, -f: file, -J: xz format） sudo tar xf GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal.tar.xz # 查看解压结果（应生成一个以版本号命名的目录） ls -ld GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal为什么必须用sudo？
/usr/local是系统级目录，普通用户无写权限；wget下载的文件属主为当前用户，但后续tar xf会继承该属主，导致 mysqld 进程无法读取其 own 目录下的bin/mysqld—— 必须由 root 执行全程，确保所有文件属主为 root。
3.2 创建 mysql 系统用户：不是为了“安全”，而是满足 mysqld 的进程降权要求
GreatSQL（及所有 MySQL 兼容分支）强制要求：mysqld主进程不能以 root 身份运行。它在启动时会主动setuid()到指定用户（默认mysql），若该用户不存在，启动直接失败，日志报Fatal error: Can't change to run as user 'mysql'。
# 创建 mysql 用户组（-g: group name） sudo /sbin/groupadd mysql # 创建 mysql 用户（-g: primary group, -d: home dir, -s: shell） sudo /sbin/useradd -g mysql mysql -d /dev/null -s /sbin/nologin # 验证用户创建成功（输出应包含 mysql:x:27:27::/dev/null:/sbin/nologin:/bin/bash） getent passwd mysql参数深挖：
-d /dev/null：禁止该用户拥有真实家目录，避免权限混乱；-s /sbin/nologin：彻底禁用登录 Shell，符合服务账户最小权限原则；getent passwd mysql比id mysql更可靠，它直接查/etc/passwd，不受缓存影响。
3.3 目录权限与属主设置：/var/lib/mysql不是“随便 chown”，而是数据目录的法定归属
mysqld 启动时，会检查数据目录（默认/var/lib/mysql）的属主是否为mysql:mysql。若属主错误（如 root:root），它会拒绝启动并报错InnoDB: Operating system error number 13 in a file operation（Permission denied）。这不是警告，是硬性校验。
# 创建数据目录（若不存在） sudo mkdir -p /var/lib/mysql # 创建日志目录（实验报告未提，但 my.cnf 中 log-error 指向 /var/log，需提前准备） sudo mkdir -p /var/log/greatsql # 修改属主（递归 -R，用户:组） sudo chown -R mysql:mysql /var/lib/mysql /var/log/greatsql /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal # 验证权限（关键目录应显示 mysql:mysql） ls -ld /var/lib/mysql /var/log/greatsql ls -ld /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal避坑 / 常见问题 / 排查
现象：
systemctl start greatsql后systemctl status greatsql显示failed，journalctl -u greatsql最后一行是mysqld: Can't create/write to file '/var/lib/mysql/is_writable' (Errcode: 13)
原因：/var/lib/mysql目录存在，但属主不是mysql:mysql，或父目录/var/lib权限太严（如drwxr-x---）
解决：sudo chown -R mysql:mysql /var/lib/mysql，并检查ls -ld /var/lib，确保mysql组有x权限（drwxr-xr-x或drwxr-x---均可）现象：
mysqld进程启动后立即退出，journalctl -u greatsql显示Plugin 'FEDERATED' is disabled.后无其他错误
原因：/usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal目录属主不是mysql，导致 mysqld 无法读取lib/plugin/下的动态库
解决：sudo chown -R mysql:mysql /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal现象：
systemctl daemon-reload后systemctl enable greatsql报Failed to execute operation: No such file or directory
原因：/lib/systemd/system/greatsql.service文件内容有语法错误（如[Service]段落缺少Type=或ExecStart=），或文件编码非 UTF-8（Windows 编辑器保存的 BOM 头）
解决：用sudo vim /lib/systemd/system/greatsql.service重新编辑，确保无 BOM（:set nobomb），并严格按下一节格式书写现象：
mysql -u root -p连接时报ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)，但密码确定正确
原因：GreatSQL 8.0.32 默认启用--skip-grant-tables模式初始化，首次启动后 root 密码为空，但实验报告未说明初始化步骤
解决：首次启动前，先手动初始化数据目录：sudo -u mysql /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal/bin/mysqld --initialize --user=mysql --datadir=/var/lib/mysql --basedir=/usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal，然后从日志/var/log/greatsql/error.log中提取临时密码（A temporary password is generated for root@localhost: xxx）
4. systemd 服务配置与全局配置文件：my.cnf不是模板，是性能与安全的开关矩阵
GreatSQL 作为企业级分支，其配置远不止port=3306这种基础项。实验报告要求编辑/etc/my.cnf，但没给出内容——这恰恰是学生最容易“抄错”或“漏配”的地方。一份合格的my.cnf，必须同时满足三个条件：能启动、能连上、能支撑后续实验（建库、建表、索引）。下面给出经实测验证的最小可行配置。
4.1 编写greatsql.service：systemd 不是“启动脚本”，而是进程生命周期管家
GreatSQL 官方不提供 systemd unit 文件，需手动创建。这个文件决定了systemctl start时如何调用mysqld、以什么用户身份运行、如何捕获日志、失败后是否重启。写错一个参数，服务就起不来。
# 创建 service 文件（必须用 sudo，路径固定为 /lib/systemd/system/） sudo tee /lib/systemd/system/greatsql.service > /dev/null << 'EOF' [Unit] Description=GreatSQL Server Documentation=man:mysqld(8) Documentation=https://greatsql.cn/docs/ After=network.target [Service] Type=simple User=mysql Group=mysql RuntimeDirectory=greatsql RuntimeDirectoryMode=0755 ExecStart=/usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal/bin/mysqld --defaults-file=/etc/my.cnf Restart=on-failure RestartSec=10 TimeoutSec=600 LimitNOFILE=65536 LimitNPROC=65536 Environment="LD_LIBRARY_PATH=/usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal/lib" [Install] WantedBy=multi-user.target EOF关键参数解析：
Type=simple：表示 ExecStart 启动的进程即主进程（不是 fork 出来的子进程），systemd 直接监控它；User=mysql&Group=mysql：强制以 mysql 用户身份运行，与前面创建的用户匹配；ExecStart：必须指定--defaults-file=/etc/my.cnf，否则 mysqld 会去读/etc/my.cnf.d/下的碎片配置，行为不可控；LimitNOFILE=65536：提高文件描述符上限，避免高并发时Too many open files错误；Environment="LD_LIBRARY_PATH=..."：显式声明动态库路径，解决libgreatsql.so等自定义库找不到的问题。
4.2 编写/etc/my.cnf：12 行配置撑起整个实验平台
实验报告只要求“编辑 my.cnf”，但没给内容。以下配置是经过郑州大学实验环境实测的最小集，兼顾兼容性（适配 GreatSQL 8.0.32）、安全性（禁用远程 root 登录）、可用性（支持中文、大事务）：
# 创建全局配置文件（覆盖式写入） sudo tee /etc/my.cnf > /dev/null << 'EOF' [client] port = 3306 socket = /var/lib/mysql/mysql.sock [mysqld] # 基础路径 basedir = /usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal datadir = /var/lib/mysql socket = /var/lib/mysql/mysql.sock pid-file = /var/run/greatsql.pid # 网络与安全 port = 3306 bind-address = 127.0.0.1 skip-networking = 0 max_connections = 200 # 字符集（支持中文实验数据） character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci init_connect = 'SET NAMES utf8mb4' # 日志 log-error = /var/log/greatsql/error.log slow_query_log = 1 slow_query_log_file = /var/log/greatsql/slow.log long_query_time = 2 # 兼容性（适配教材 SQL 示例） sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION EOF为什么这样配？
bind-address = 127.0.0.1：只监听本地回环，杜绝实验环境意外暴露；character-set-server = utf8mb4：utf8在 MySQL 中实际是utf8mb3，不支持 emoji 和部分生僻汉字，utf8mb4才是真正的 UTF-8；init_connect = 'SET NAMES utf8mb4'：确保每个新连接自动设置字符集，避免INSERT INTO students VALUES ('张华', ...)存成乱码；sql_mode严格化：禁用NO_AUTO_CREATE_USER（GreatSQL 8.0+ 已废弃该模式，但保留可兼容旧教材 SQL）；slow_query_log开启：后续实验做查询优化（如索引对比）时，可直接分析慢日志验证效果。
4.3 重载 systemd 并启用服务：daemon-reload不是仪式，是配置生效的必经之路
写完 service 和 my.cnf，必须让 systemd 重新加载配置，否则systemctl start仍会用旧的、不存在的 unit 文件。
# 重载 systemd 配置（使 new .service 文件生效） sudo systemctl daemon-reload # 启用开机自启（非必须，但实验环境建议开启） sudo systemctl enable greatsql # 启动服务 sudo systemctl start greatsql # 检查状态（关键看 Active: active (running)） sudo systemctl status greatsql验证要点：
Active: active (running)表示服务已成功拉起；Main PID:后的数字应与ps -ef | grep mysqld输出的 PID 一致；- 若显示
active (exited)，说明 ExecStart 执行完就退出了（常见于 my.cnf 路径错误或 mysqld 二进制路径错误）； - 若显示
failed，立即执行sudo journalctl -u greatsql -n 50 --no-pager查看最后 50 行日志。
5. 启动验证与首次登录：mysql -u root -p连不上？先看 error.log 里藏着的临时密码
GreatSQL 8.0.32 沿用 MySQL 5.7+ 的安全策略：首次初始化后，root 用户密码不是空，而是一个随机生成的临时密码，必须从错误日志中提取。这是实验报告里没明说、但几乎每个学生都会卡住的点。
5.1 检查 mysqld 进程与端口监听：确认服务真的“活”着
# 查看进程（应看到 mysqld --defaults-file=...） ps -ef | grep mysqld | grep -v grep # 查看端口（应看到 LISTEN 3306） sudo ss -ltnp | grep :3306 # 查看数据目录内容（初始化后应有 ibdata1、ib_logfile0 等文件） sudo ls -lh /var/lib/mysql/现象解读：
ps输出中若只有mysqld_safe没有mysqld，说明 mysqld 主进程崩溃退出；ss无输出，说明 mysqld 未监听任何端口，大概率是 my.cnf 中port或bind-address配置错误；/var/lib/mysql/为空，说明mysqld --initialize从未执行，需手动初始化（见 3.3 节排查第 4 条）。
5.2 提取 root 临时密码：error.log 是唯一真相来源
GreatSQL 初始化时，会将 root 临时密码写入log-error指定的日志文件。必须用sudo查看，因为日志属主是mysql。
# 确保日志目录可读 sudo chmod 755 /var/log/greatsql # 查找临时密码（关键词 "temporary password"） sudo grep "temporary password" /var/log/greatsql/error.log典型输出：
2024-03-15T08:22:34.123456Z 1 [Note] A temporary password is generated for root@localhost: aB3#xY9!mQ2@pL8密码规则：
- 长度 12 位，含大小写字母、数字、特殊字符；
- 仅首次有效，登录后必须立即修改（GreatSQL 强制要求）；
- 若日志中无此行，说明初始化未触发，需手动执行
sudo -u mysql /usr/local/.../bin/mysqld --initialize --user=mysql --datadir=/var/lib/mysql --basedir=/usr/local/...。
5.3 首次登录与密码修改：ALTER USER是唯一合法途径
GreatSQL 8.0.32 禁用SET PASSWORD语法，必须用ALTER USER。
# 使用临时密码登录（-h127.0.0.1 强制走 TCP，-p 后不跟密码，回车后输入） mysql -h127.0.0.1 -P3306 -u root -p # 在 MySQL 提示符下修改密码（必须包含大小写字母、数字、特殊字符，长度≥8） ALTER USER 'root'@'localhost' IDENTIFIED BY 'ZhengDa2024!'; # 刷新权限（立即生效） FLUSH PRIVILEGES; # 退出 EXIT;验证新密码：
# 用新密码重新登录（应成功） mysql -h127.0.0.1 -P3306 -u root -pZhengDa2024! # 查看当前用户（确认是 root@localhost） SELECT USER(), CURRENT_USER();常见错误：
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements：密码强度不足，需增加长度或特殊字符；ERROR 1045 (28000): Access denied：密码输错，或用了-p后直接跟密码（如-pZhengDa2024!），GreatSQL 会把!当作 shell 特殊字符截断，务必用-p回车后输入。
6. 实验一核心功能验证：用一条SHOW DATABASES;确认整个环境链路跑通
装完 GreatSQL，不代表实验平台就 ready 了。郑州大学实验一的终极目标，是让学生能亲手执行CREATE DATABASE DB;、USE DB;、SHOW TABLES;这些基础命令，并观察到预期结果。下面是一套“五步验证法”，每一步都对应一个关键组件，任一环节失败，都能精准定位问题模块。
6.1 验证客户端连接能力：mysql --version与mysql -V的区别
GreatSQL 的客户端mysql二进制位于bin/目录下，必须将其加入 PATH，否则mysql命令不可用。
# 将 GreatSQL 的 bin 目录加入 PATH（临时） export PATH="/usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal/bin:$PATH" # 验证客户端版本（应显示 GreatSQL 8.0.32） mysql --version # 验证详细版本（含编译参数） mysql -V为什么必须加 PATH？
- 实验报告中所有
mysql命令都默认在 PATH 中； - 若不加，每次都要写全路径
/usr/local/.../bin/mysql，极其繁琐； - 加入
/etc/profile可永久生效：echo 'export PATH="/usr/local/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64-minimal/bin:$PATH"' | sudo tee -a /etc/profile && source /etc/profile。
6.2 验证服务端响应：mysqladmin ping是比ps更可靠的存活探测
ps只看进程是否存在，mysqladmin ping才真正测试 mysqld 是否能响应 SQL 请求。
# 使用 root 用户探测（-p 后回车输密码） mysqladmin -h127.0.0.1 -P3306 -u root -p ping # 预期输出：mysqld is alive失败场景与对策：
mysqladmin: connect to server at '127.0.0.1' failed：网络不通，检查ss -ltnp | grep 3306；Access denied for user 'root'@'localhost'：密码错误，重新执行 5.3 节；Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'：socket 路径错误，检查 my.cnf 中socket配置是否与mysqladmin默认路径一致（可加--socket=/var/lib/mysql/mysql.sock强制指定）。
6.3 验证基础 SQL 执行：CREATE DATABASE是数据库功能的黄金标准
执行教材要求的CREATE DATABASE DB;，并验证其物理落地。
# 登录并建库 mysql -h127.0.0.1 -P3306 -u root -p -e "CREATE DATABASE DB;" # 查看数据库列表（应包含 DB） mysql -h127.0.0.1 -P3306 -u root -p -e "SHOW DATABASES;" # 查看 DB 数据库的物理路径（/var/lib/mysql/ 下应有 DB 目录） sudo ls -ld /var/lib/mysql/DB关键检查点：
SHOW DATABASES;输出中必须有DB，且大小写敏感（GreatSQL 默认lower_case_table_names=1，但库名区分大小写）；/var/lib/mysql/DB/目录必须存在，且属主为mysql:mysql；- 若
CREATE DATABASE成功但SHOW DATABASES不显示，说明information_schema视图损坏，需重启服务。
6.4 验证逻辑组件可见性：SHOW TABLES;和SELECT * FROM information_schema.SCHEMATA;
GreatSQL 的information_schema是只读视图，存储所有元数据。实验一要求了解“基本表、视图、触发器”，这些都藏在这里。
# 连接 DB 库并查看空表（应返回 Empty set） mysql -h127.0.0.1 -P3306 -u root -p -e "USE DB; SHOW TABLES;" # 查询所有数据库（验证 information_schema 可用） mysql -h127.0.0.1 -P3306 -u root -p -e "SELECT SCHEMA_NAME FROM information_schema.SCHEMATA;" # 查询所有触发器（应返回空，因尚未创建） mysql -h127.0.0.1 -P3306 -u root -p -e "SELECT TRIGGER_NAME FROM information_schema.TRIGGERS;"为什么查information_schema？
- 它是 DBMS 自身的“数据库字典”，证明 GreatSQL 内核已完整加载；
SCHEMATA表列出所有数据库，TRIGGERS表列出所有触发器，是实验一“逻辑组件”要求的直接证据；- 若
SELECT FROM information_schema报错，说明 mysqld 初始化不完整，需重新--initialize。
6.5 验证物理组件可访问：ls /var/lib/mysql/与du -sh /var/lib/mysql/
数据库的物理存在，最终体现为磁盘上的文件。/var/lib/mysql/目录结构就是 GreatSQL 物理架构的具象化。
# 列出数据目录核心文件（必须存在） sudo ls -lh /var/lib/mysql/ | grep -E "(ibdata1|ib_logfile|mysql.sock|DB)" # 查看总大小（初始化后约 100MB，证明数据文件已生成） sudo du -sh /var/lib/mysql/ # 查看 ibdata1 文件（InnoDB 共享表空间，是物理存储的核心） sudo ls -lh /var/lib/mysql/ibdata1文件意义速查表：
| 文件名 | 类型 | 作用 | 实验一关联点 |
|---|---|---|---|
ibdata1 | InnoDB 共享表空间 | 存储数据字典、undo logs、系统表 | “物理存储单位是数据页”的实证 |
ib_logfile0/1 | Redo Log 文件 | 记录事务变更，保证崩溃恢复 | “事务一致性”的底层支撑 |
mysql.sock | Unix Socket 文件 | 本地连接的 IPC 通道 | mysql -S /var/lib/mysql/mysql.sock的依据 |
DB/目录 | 数据库目录 | 存放 DB 库下所有表的.frm、.ibd文件 | CREATE DATABASE DB的物理映射 |
从那以后我每次部署 GreatSQL，都强制走一遍这五步验证：mysql --version→mysqladmin ping→CREATE DATABASE→SELECT FROM information_schema→ls /var/lib/mysql/。少一步，心里就不踏实。因为实验平台不是“能跑就行
本文还有配套的精品资源，点击获取
