mysql 8.0 安装后必须先查错误日志获取临时root密码并修改，否则无法登录；默认caching_sha2_password插件不兼容旧客户端，需指定mysql_native_password或更新连接参数；不可见索引不能用于主键/唯一约束，降序索引依赖新排序规则；performance_schema和sys默认启用但需合理配置采集项。
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已合理设置，否则该视图数据无意义
真正影响线上稳定性的，往往不是新功能多炫酷，而是默认值变了、插件换了、日志位置藏得更深了——这些细节不查文档、不看错误日志，光靠“照着教程敲”基本必挂。
