数据库的操作与踩过的坑

最近上线一个项目,采用的数据库是mysql,在部署的过程中碰到不少问提,总结出来:

1、对于线上的数据库连接,用navicat for mysql 连接线上数据库注意事项:

 1)常规里面填写的用户名和密码以及端口号是你要连接的数据库的用户名、密码和端口号;

 2)ssh里面填写的用户名和密码是你连接的服务器的用户名和密码;

2、将表assets_asset中的id插入到表assets_disk中asset_id

insert into assets_cpu (asset_id) select id from assets_asset
清空数据:truncate table name

3数据库批量操作

(1)例1、将来自表assets_asset的id插入assets_cpu表数据asset_id:

insert into assets_cpu (asset_id) select id from assets_asset
where id not in (select asset_id from assets_cpu) 

例2、将表assets_asset字段id,1赋值到表assets_asset_tags两个字段asset_id,tag_id:

insert into assets_asset_tags (asset_id,tag_id)
select distinct id,1 from assets_asset

Tip:select distinct 有distinct这个keyword来过滤掉多余的反复记录仅仅保留一条;

(2)清空表数据

truncate table assets_server

 (3)批量更新a表的name到b表的hosted_on_id:

update assets_server a set hosted_on_id = (select name from assets_asset b where a.asset_id = b.id)

 

4查看数据库已授权用户:

SELECT DISTINCT CONCAT('User: ''',user,'''@''',host,''';') AS query FROM mysql.user;

 

mysql启动服务:

systemctl start mariadb.service

mysql修改密码

set password=password('123456');

数据库授权远程登陆:

grant all privileges on *.* to 'root'@'%' identified by '1234!@#$abc';
flush privileges;

5、采用Django框架的时候,项目需要做数据库映射,采用python3 manage.py makemigrations 发现自己定义的model没有生成时,这时候我们可以先进行一个手动的操作:

python3.6 manage.py makemigrations --empty assets ###assets是你建立的appname;

做完这一个之后,在执行python3.6 manage.py makemigrations语句时就不会弹出No changes detected

6、快速建表,并且避免错误:

CREATE TABLE 'assets_cpu' ('id' int(10) NOT NULL auto_increment,PRIMARY KEY  ('id')) ENGINE=InnoDB DEFAULT CHARSET=utf8;

7、如果报错某个表exist,则运行:

python3 manage.py showmigrations

显示出所有的app及对应的已经生效的migration文件

python3.6 manage.py migrate –fake pay zero

truncate table  name

8、数据库结构操作:

(1)函数操作:

###数据库新建多条自增id值,id的自增区间为4到255:
BEGIN 
DECLARE i INT DEFAULT 258;
WHILE i<255 and i>4 
DO 
insert into assets_ipaddress SET id = i+1; 
SET i=i+1; 
END WHILE ; 
commit; 
END

 9、查看指定数据库所占内存空间大小:

use information_schema--此命令是使用数据库是MySQL自带的信息数据库,保存着关于MySQL服务器所有其他数据库的信息,类似于数据字典,如数据库名,表名,表的访问权限,列名,索引,约束等
select concat(round(sum(DATA_LENGTH)/1024/1024+sum(INDEX_LENGTH)/1024/1024),'M') 
from information_schema.tables where table_schema=‘fupu_daas_cmdb’;

10、新建django项目的时候出现报错:'Did you install mysqlclient or MySQL-python'

 解决办法:pip install mysql-python;

在app的__init__.py中加入:

import pymysql

pymysql.install_as_MySQLdb()

11、数据库操作:

#增加字段:

insert into assets_ipaddress(alibe_ip) values ('10.10.66.11')

#删除字段:

delete from assets_ipaddress where dead_ip='10.10.66.11'

#删除某列字段:alter table assets_ipaddress drop column memo;

#当表assets_asset中的name字段不存在于表assets_ip_tags时,将来自表assets_asset的id和name插入到表assets_ip_tags中的asset_id,ip两个字段:

insert into assets_ip_tags (asset_id,ip) select id,name from assets_asset where name not in (select ip from assets_ip_tags)

#更新表assets_server的hosted_on_id字段,此字段来源于表assets_asset的name字段:

update assets_server a set hosted_on_id = (select name from assets_asset b where a.asset_id=b.id)

#当出现IP资源池点击不正确的时候,用它:

update assets_ip_tags a set asset_id=(select id from assets_asset b where a.ip=b.name)
delete from assets_ip_tags where ip not in (select name from assets_asset)

12、当数据库远程连接出现报错Access denied for user 'root'@'localhost' (using password:yes)时:

解决办法:在/etc/my.cnf的[mysqld]下加一句话:skip-grant-tables;

13、python Django开发的时候,需要进行数据库接口连接与操作的问题:

突然出现某个数据库相关的操作,报错(2006, "MySQL server has gone away (BrokenPipeError(32, 'Broken pipe'))")
原因:即某个mysql长连接很久没有新的请求发起,达到了server端的timeout,被server强行关闭。
此后再通过这个connection发起查询的时候,就会报错server has gone away
解决办法:/etc/my.cnf下添加:
wait_timeout=2880000
interactive_timeout = 2880000

  

 

 

 

 

 

转载于:https://www.cnblogs.com/haoxinchen/p/9506909.html

<think>嗯,用户的问题是关于千万级数据表下如何保证系统高可用性和进行数据库优化的综合方案。从引用的资料来看,用户已经对分库分表、索引优化等基础概念有所了解,但更关注的是系统层面的可用性保障。用户可能是运维工程师或架构师,正在面临实际的生产环境性能压力。ta特意强调了“系统高可用性”和“解决方案”,说明需求非常务实,需要能落地的方案而非理论。引用3中提到的大表性能问题制约系统效能,应该就是ta当前遇到的痛点。深层需求可能是:如何在数据量持续增长的情况下,避免因数据库瓶颈导致服务中断。尤其是电商、社交这类对可用性要求极高的场景,用户需要的是能支撑业务连续性的架构方案。结合四篇引用的核心信息:-引用1点明了分库分表是解决单表性能瓶颈的关键路径-引用2强调查询优化需要多维度策略组合-引用3揭示了硬件升级和SQL改写的重要性-引用4则警告了分区表的局限性需要特别注意引用4中作者反对使用MySQL分区表的观点,这可能是用户容易。在方案设计时要突出更可靠的Sharding方案。高可用设计要覆盖三个层面:1基础设施层(如引用3提到的硬件升级)2数据层(如引用1的分库分表)3应用层(如引用2的缓存机制)用户没有提到具体数据库类型,但引用都是MySQL相关,按MySQL方案设计。不过NoSQL方案也应作为补充选项,这点引用1有提及但未展开。监控部分虽然引用未直接说明,但根据引用2“持续优化”的提示,必须加入实时监控方案。可以结合PerconaToolkit这类专业工具。最后的“生成相关问题”环节,要引导用户考虑具体实施细节:-数据迁移如何不停机?-分片键怎么选?-要不要引入NewSQL?这些才是真正决定方案成败的关键点。方案描述时要避免过于技术化,比如“分库分表”可以具象为“订单表按月分表”的实例。用户需要的是能直接映射到业务场景的解决方案。</think> 针对千万级数据表下的系统高可用性数据库优化,结合最佳实践引用资料,以下是综合解决方案: --- ### **一、核心优化策略** 1. **分库分表**(核心方案) - **垂直拆分**:按业务模块分离(如用户表/订单表独立到不同库)[^1][^4] - **水平拆分**: - **分表**:单表数据按规则拆分(如订单表按月分表`order_2023_01`) - **分库**:数据分散到多个物理库(如按用户ID哈希分库) - **工具支持**:使用ShardingSphere、MyCat等中间件简化管理 2. **深度索引优化** - **覆盖索引**:仅通过索引获取数据,避免回表(`EXPLAIN`的`Extra`列出现`Using index`)[^2] - **复合索引**:按查询频率排序字段(如`(user_id, create_time)`) - **定期重建索引**:`ALTER TABLE tbl_name ENGINE=INNODB` 解决碎片化问题[^3] 3. **查询语句优化** ```sql -- 反例:全表扫描 + 文件排序 SELECT * FROM orders WHERE status=1 ORDER BY create_time DESC; -- 正例:索引覆盖 + 分页优化 SELECT id, amount FROM orders WHERE status=1 AND create_time > '2023-01-01' ORDER BY create_time DESC LIMIT 100; ``` - 禁用`SELECT *`,分批处理大量数据(`LIMIT`分页改用`WHERE id>last_id`)[^2] --- ### **二、高可用架构设计** 1. **集群化部署** ![](https://example.com/db-ha-arch.png) *(示意图:MySQL高可用架构)* - **主从复制**:一主多从架构,读请求分流到从库 - **故障转移**:基于Keepalived或MHA实现主库故障自动切换 - **数据一致性**:半同步复制(Semi-Sync Replication)确保主从强一致 2. **缓存加速层** | 缓存策略 | 适用场景 | 工具 | |----------------|-------------------------|---------------| | 查询结果缓存 | 高频读低频写 | Redis/Memcached | | 数据库缓冲池 | 减少磁盘IO | InnoDB Buffer Pool | | 二级缓存 | ORM框架级缓存 | Ehcache/Hibernate | 3. **异步化处理** ```mermaid graph LR 用户请求-->API服务器-->消息队列-->DB写入Worker 消息队列-->备用写入路径[(应急存储)] ``` - 消峰填谷:用Kafka/RabbitMQ缓冲高并发写入 - 最终一致性:非核心操作异步处理(如日志记录) --- ### **三、补充优化手段** 1. **硬件参数调优** - **SSD存储**:随机IO性能提升10倍以上 - **参数调整**: ```ini innodb_buffer_pool_size = 系统内存的70-80% innodb_flush_log_at_trx_commit = 2 # 折衷性能安全 ``` 2. **规避分区表陷阱** - 引用[^4]明确指出:分区表难以水平扩展,优先选择分库分表而非分区 - 分区仅适用于数据归档场景(如按年分区删除旧数据) 3. **新型技术栈融合** | 场景 | 推荐方案 | |--------------------|-------------------| | 实时分析 | TiDB/ClickHouse | | 超高频读写 | Redis Cluster | | 全文搜索 | Elasticsearch | --- ### **四、监控应急机制** 1. **实时监控指标** - 数据库:QPS/TPS、线程阻塞、慢查询日志 - 硬件:磁盘IOPS、网络带宽、CPU负载 - 工具:Prometheus+Grafana+Percona Monitoring Tools 2. **熔断降级** - 读请求降级:从库延迟过高时返回缓存旧数据 - 写请求限流:Guava RateLimiter控制入库速率 > **关键结论**:千万级数据表的高可用需**分库分表奠基 + 读写分离扩展 + 缓存加速 + 异步解耦**四层协同,配合精细化监控实现可持续扩展[^1][^2][^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值