MySQL 8.0 安装后必须立即执行的初始化操作
跳过这步会导致后续无法登录、权限混乱，甚至
root@localhost账户被锁定。安装完 MySQL 8.0（尤其是通过官方
mysql-installer或
apt/
brew安装）后，不要直接尝试用
mysql -u root -p登录——默认 root 密码不是空，也不是随机生成并打印在终端，而是由
mysqld --initialize写入错误日志或临时文件。
实操建议：
Linux/macOS：检查/var/log/mysqld.log或
/usr/local/mysql/data/*.err，搜索
A temporary password is generated找到初始密码 Windows：查看
C:\ProgramData\MySQL\MySQL Server 8.0\Data\*.err（注意
ProgramData是隐藏目录） 首次登录后立刻执行：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourStrongPass123!';如果跳过初始化直接启动服务，可能触发
ERROR 1045 (28000): Access denied，此时需临时跳过权限验证重启：
mysqld --skip-grant-tables --skip-networking，再手动更新
mysql.user表
MySQL 8.0 默认身份验证插件导致客户端连接失败
MySQL 8.0 默认使用
caching_sha2_password插件，而老版本客户端（如 MySQL Workbench 6.x、Navicat 旧版、PHP 7.2 以下 mysqli 扩展）不支持，会报错
Client does not support authentication protocol requested by server。
解决方法取决于你是否能升级客户端：
兼容旧客户端：创建用户时显式指定插件：CREATE USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'pass';全局降级（不推荐生产）：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pass';，并修改
my.cnf中的
default_authentication_plugin=mysql_native_password确认当前用户插件：
SELECT user, host, plugin FROM mysql.user;注意：JDBC 连接需加参数
?serverTimezone=UTC&allowPublicKeyRetrieval=true&useSSL=false，否则即使插件正确也可能握手失败
MySQL 8.0 的不可见索引与降序索引怎么用才不踩坑
这两个是 8.0 新增的实用特性，但容易误用或忽略限制。
不可见索引（Invisible Index）：
用于灰度下线索引：执行ALTER TABLE t1 ALTER COLUMN idx_name INVISIBLE;，优化器将忽略它，但索引仍被维护（写入开销不变） 不能对主键或唯一约束索引设为不可见；也不能对全文索引、空间索引设为不可见 查看是否可见：
SELECT INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't1';
降序索引（Descending Index）：
支持混合排序：CREATE INDEX idx ON t1 (a ASC, b DESC, c ASC);，可覆盖
ORDER BY a, b DESC, c查询 注意：MySQL 8.0 仅在
utf8mb4_0900_as_cs等新排序规则下才真正按字节降序存储；老排序规则（如
utf8mb4_general_ci）实际仍是升序构建，只是优化器“假装”支持 执行
SHOW CREATE TABLE t1可确认索引定义中是否含
DESC
performance_schema 和 sys schema 在 8.0 中的默认启用差异
MySQL 8.0 默认开启更多监控项，但部分配置项行为变更，容易引发性能误判或查询超时。
关键点：
performance_schema默认启用（
performance_schema=ON），且新增了
wait/lock/metadata/sql/mdl等等待事件，但采集粒度变细，高并发下自身开销上升约 5–10%
sysschema 默认启用，但其视图依赖
performance_schema，若手动关闭后者，
sys视图将返回空或报错
Table performance_schema.xxx doesn't exist常见误操作：为“提升性能”盲目关闭
performance_schema，结果导致慢查询无法归因、锁等待无法分析；应优先调整采集开关，如：
UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE 'events_waits%';8.0 中
sys.schema_table_statistics_with_buffer替代了旧版的
schema_table_statistics，新增了缓冲池读取统计，但需确保
innodb_buffer_pool_size已合理设置，否则该视图数据无意义
真正影响线上稳定性的，往往不是新功能多炫酷，而是默认值变了、插件换了、日志位置藏得更深了——这些细节不查文档、不看错误日志，光靠“照着教程敲”基本必挂。
