Mysql 单机多实例密码丢失的处理

本文介绍了一种通过停用MySQL服务,使用skip-grant-tables参数启动来绕过密码验证,然后利用UPDATE语句修改MySQL管理员密码的方法。最后,通过正常方式重启MySQL服务,并使用新密码登录。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.停用mysql
2.使用skip-grant-tables参数启动
3.update语句更新密码
4.重开mysql,正常登录密码更改后的mysql


1.停用mysql

#停用mysql 如若没有密码也只能killall mysqld ,这里我有密码只是演示所以还是平滑关闭
[root@master01 bin]# mysqladmin -uroot -poracle -S /data/3307/mysql.sock shutdown
[root@master01 bin]# netstat -lntup|grep 330


2.使用skip-grant-tables参数启动

#使用skip-grant-tables参数启动mysql,忽略授权登录验证
[root@master01 bin]# mysqld_safe --defaults-file=/data/3307/my.cnf  --skip-grant-tables --user=mysql

#无密码方式登录mysql
[root@master01 bin]#  mysql -uroot -S /data/3307/mysql.sock
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.39-log Source distribution

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

#利用update 语句更新用户密码
mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
3.update语句更新密码

mysql> update user set password=password('oracle123456') where user='root';
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

mysql>  flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> \q
Bye


4.重开mysql,正常登录密码更改后的mysql

#使用更新密码关闭mysql并开启
[root@master01 ~]# mysqladmin -uroot -poracle123 -S /data/3307/mysql.sock shutdown

#启动mysql 3307
[root@master01 bin]# mysqld_safe --defaults-file=/data/3307/my.cnf  --user=mysql

#登录mysql
[root@master01 bin]#  mysql -uroot -S /data/3307/mysql.sock -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.5.39-log Source distribution
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

OK
<think>嗯,用户问的是MySQL有1亿多条数据怎么优化。首先,我需要考虑用户的使用场景。这么大的数据量,可能是在处理高并发的应用,比如电商平台或者社交网络,或者是数据分析的场景。用户可能是后端开发人员或者数据库管理员,他们遇到了性能问题,比如查询慢、写入延迟,或者系统资源消耗过高。 接下来,用户的需求是什么?他们可能希望优化查询速度,减少响应时间,提高系统吞吐量,或者降低成本。深层需求可能包括系统的可扩展性、稳定性,以及未来的维护成本。需要考虑到用户可能对分库分表、索引优化等概念有一定了解,但需要具体的步骤和建议。 首先,我会想到索引优化。一亿条数据没有合适的索引,查询肯定会慢。但索引过多也会影响写入性能,所以需要平衡。然后,分库分表是处理大数据量的常用方法,但具体怎么分?垂直分还是水平分?分片键的选择很重要,比如按用户ID哈希或者时间范围。 然后是硬件和配置调整。内存不足的话,InnoDB缓冲池可能不够,需要调整参数。连接数设置是否合理?最大连接数如果太低,高并发时会有问题。还有查询缓存,虽然MySQL 8.0已经移除了,但如果是旧版本可能需要考虑是否启用。 SQL语句优化也是关键,避免全表扫描,使用EXPLAIN分析执行计划。慢查询日志可以帮助定位问题。还有事务的使用,避免长事务占用资源。 归档历史数据,冷热数据分离。比如把旧数据迁移到归档表,或者使用分区表按时间分区。这样查询当前数据时会更快。 主从复制和读写分离,分担主库压力。读多写少的场景可以用多个从库来处理查询。还有考虑使用缓存层,比如Redis,减少数据库的直接访问。 如果单机已经无法应对,可能需要考虑云数据库的分布式方案,或者TiDB这样的NewSQL数据库。同时,定期维护,比如重建索引、统计信息更新,也很重要。 最后,可能需要分阶段实施,先优化索引和SQL,再调整配置,最后考虑架构上的分库分表或迁移到分布式系统。需要提醒用户根据具体业务场景选择合适的方案,测试后再逐步实施。</think>好的,我将分步骤为您梳理MySQL亿级数据优化方案。以下为经过工业验证的核心优化策略,按优先级排序: 一、架构优化(成本高但效果显著) 1. 分库分表方案 - 垂直拆分:按业务模块拆分(如用户库/订单库) - 水平拆分:采用Sharding策略 ```sql -- 示例:按用户ID哈希分片 CREATE TABLE orders_0 ( id BIGINT PRIMARY KEY, user_id INT, shard_id INT GENERATED ALWAYS AS (user_id % 4) STORED ) PARTITION BY LIST (shard_id) ( PARTITION p0 VALUES IN (0), PARTITION p1 VALUES IN (1), PARTITION p2 VALUES IN (2), PARTITION p3 VALUES IN (3) ); ``` - 分片键选择原则:离散度高、业务相关性强的字段 2. 读写分离架构 - 主库集群:1主 + M从(处理写操作) - 从库集群:N个只读实例(处理读操作) - 使用ProxySQL或MySQL Router实现流量分发 二、存储引擎优化 1. InnoDB关键参数配置 ```ini innodb_buffer_pool_size = 物理内存的70%-80% innodb_flush_log_at_trx_commit = 2(允许丢失1s数据) innodb_file_per_table = ON innodb_flush_method = O_DIRECT ``` 2. 分区表实践(适用于时间序列数据) ```sql CREATE TABLE sensor_data ( id INT AUTO_INCREMENT, ts DATETIME, value FLOAT, PRIMARY KEY (id, ts) ) PARTITION BY RANGE (YEAR(ts)) ( PARTITION p2020 VALUES LESS THAN (2021), PARTITION p2021 VALUES LESS THAN (2022), PARTITION p2022 VALUES LESS THAN (2023) ); ``` 三、索引优化策略 1. 索引设计黄金法则 - 联合索引遵循最左前缀原则 - 区分度高的字段在前 - 避免过度索引(维护成本增加20%写入开销) 2. 索引失效场景检测 ```sql EXPLAIN SELECT * FROM orders WHERE DATE(create_time) = '2023-01-01'; -- 错误用法 ``` 四、查询优化实践 1. 高效分页方案 ```sql -- 传统分页(避免) SELECT * FROM table LIMIT 1000000, 20; -- 优化方案(游标分页) SELECT * FROM table WHERE id > 1000000 ORDER BY id LIMIT 20; ``` 2. 批量操作优化 ```sql -- 低效写法 INSERT INTO table VALUES (1); INSERT INTO table VALUES (2); -- 高效批量写入 INSERT INTO table VALUES (1),(2),(3); ``` 五、数据生命周期管理 1. 冷热数据分离 - 在线库:保留最近3个月数据 - 归档库:使用TokuDB引擎存储历史数据 - 归档工具:pt-archiver 六、监控与调优 1. 关键监控指标 ```sql SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; SHOW ENGINE INNODB STATUS; ``` 2. 慢查询分析 ```ini # my.cnf配置 slow_query_log = 1 long_query_time = 1 log_queries_not_using_indexes = 1 ``` 七、硬件优化建议 1. 存储方案选型 - NVMe SSD:随机IOPS需达到10万+ - RAID配置:建议RAID 10 - 文件系统:XFS或EXT4 2. 内存配置 - Buffer Pool大小计算公式: $$ \text{Buffer Pool Size} = \text{Total Data Size} \times 0.8 \times \text{Working Set Ratio} $$ 八、进阶方案 1. 分布式方案选型 - TiDB:适合HTAP场景 - AWS Aurora:云原生方案 - Vitess:分片管理方案 实施建议: 1. 优先进行索引优化和查询优化 2. 其次调整服务器配置 3. 最后实施分库分表(需业务改造) 4. 每次变更后使用sysbench进行压力测试 注:以上方案需根据实际业务场景组合使用,建议先在生产环境的从库上进行验证。对于金融级数据,需谨慎选择异步复制方案。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值