在MySQL软件安装完成后、实例初始化之前，我们可以通过修改配置文件与初始化参数，决定默认数据库的字符集、初始库的存在与否，以及表空间是采用共享还是独立文件方式。合理的安装期配置能减少后期运维成本，也能让业务数据从一开始就落在规划好的存储路径中。
一、安装阶段涉及的核心配置项
MySQL的行为主要由配置文件控制，在Linux上通常是/etc/my.cnf或/etc/mysql/my.cnf，在Windows上则是安装目录下的my.ini。安装程序本身一般不会暴露所有底层参数，因此手动编辑配置文件是更可靠的做法。与默认数据库和表空间最相关的配置包括datadir、innodb_data_file_path、innodb_file_per_table，以及字符集相关变量。
datadir决定了数据文件根目录，初始化时生成的mysql、sys等系统库都会放在这里。如果我们希望默认业务库也落在特定挂载点，应提前把datadir设好并确保目录权限属于mysql用户。表空间方面，innodb_file_per_table控制是否每张表使用独立.ibd文件；若设为OFF，所有InnoDB表数据都写入共享的ibdata文件。该值如果在安装后修改，已有表不会自动迁移，所以最好在初始化前定好。
1.1 配置文件示例
下面是一段典型的Linux下my.cnf片段，展示了安装前应如何写入默认参数：
[mysqld] # 数据目录，安装前需创建并赋权 datadir=/data/mysql/data # 使用独立表空间，每张表一个ibd文件 innodb_file_per_table=ON # 共享表空间基础文件，即使开了独立表空间也会存在 innodb_data_file_path=ibdata1:512M:autoextend # 默认字符集，避免后期乱码 character_set_server=utf8mb4 collation_server=utf8mb4_general_ci
上述配置在实例初始化（mysqld --initialize 或 mysql_install_db）时生效。若你使用的是发行版提供的包管理器安装，也应在首次启动前放好该文件，否则会沿用编译默认值。
二、默认数据库的创建与初始化脚本
MySQL初始化时会自动建立名为mysql、sys、performance_schema、information_schema的系统库，其中前三个是物理库。除此之外，很多团队希望新实例自带一个业务基础库，例如app_base，这就需要在初始化阶段注入SQL。
一种做法是初始化完成后手动登录执行CREATE DATABASE；另一种更规范的做法是在安装时通过--init-file参数指定初始化SQL文件，该文件里的语句会在系统库建好后执行。这样既保证了环境一致性，也方便用配置管理工具批量部署。
2.1 使用init-file创建默认库
假设我们准备了如下SQL文件init.sql，内容仅为建库和建表空间目录：
CREATE DATABASE IF NOT EXISTS app_base DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE app_base; CREATE TABLE IF NOT EXISTS init_flag ( id INT PRIMARY KEY, note VARCHAR(50) ) ENGINE=InnoDB;
然后在初始化命令中引用它：
mysqld --initialize --init-file=/path/to/init.sql --user=mysql
这样实例启动后就已经存在app_base库。需要注意的是，init-file中的语句必须以分号结尾，且不能包含需要交互的命令。另外，如果开了独立表空间，上述init_flag表会自动生成app_base目录下的init_flag.ibd文件，与系统库物理隔离。
三、共享表空间与独立表空间的取舍
很多人在安装时直接接受默认配置，导致所有表挤在ibdata1里。要理解如何配置，先要看清两种方式的差异。共享表空间把所有InnoDB数据集中管理，早期版本默认如此；独立表空间则让每张表有单独文件。
从运维角度看，独立表空间在删除大表后能立刻释放磁盘空间，而共享表空间即使删表，ibdata1也不会自动缩小，需用额外工具导出导入才能回收。备份时，独立文件方便用物理拷贝单表的方式迁移；共享表空间则必须整体处理。安装时开启innodb_file_per_table=ON是目前主流实践。
3.1 对比表
| 维度 | 共享表空间 | 独立表空间 |
|---|---|---|
| 空间回收 | 难，需重建 | 删表即释放 |
| 单表迁移 | 不支持 | 可拷贝ibd |
| 文件数量 | 少 | 多 |
| 安装默认 | 旧版默认 | 5.7后默认 |
如果业务存在频繁删建临时大表的场景，独立表空间优势明显。但若实例只承载极少固定表，共享方式也能减少文件句柄占用。安装前评估业务特征，再写入对应配置才是稳妥做法。
四、常见误区与避坑
有人以为在配置里写了default_database就能让MySQL自动建业务库，其实MySQL并没有该变量，所谓默认数据库只是连接时未指定库名所处的位置，系统并不会代你建库。正确做法仍是通过init-file或部署脚本完成。
另一个坑是安装后修改innodb_file_per_table却未重建表。此时新表用独立文件，旧表仍在ibdata1，排查空间问题时容易误判。因此安装时的首次配置非常关键，务必在初始化前确认好，避免后续使用ALTER TABLE ... TABLESPACE重建带来的锁表风险。
4.1 检查当前表空间模式
实例起来后，可用如下语句确认是否如安装预期：
SHOW VARIABLES LIKE 'innodb_file_per_table'; SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'app_base';
若查询显示innodb_file_per_table为ON，且数据目录下app_base文件夹中存在ibd文件，说明安装期配置已生效。此后新增业务库也会继承该表空间策略，无需重复干预。
五、总结配置流程
综合来看，安装MySQL时配置默认数据库与表空间，核心动作只有三步：编辑配置文件设定datadir和innodb_file_per_table；准备init-file写入建库语句；执行初始化命令并启动。流程虽简单，却决定了实例整个生命周期的存储形态。
对于需要多实例或容器化部署的团队，可以把上述my.cnf与init.sql做成模板，在镜像构建阶段注入。这样无论是物理机还是Kubernetes中的Pod，拉起的MySQL都自带规范好的默认库与独立表空间，省去人工登录配置的环节，也降低环境差异导致的故障率。