数据库优化

某年某月某日的一个下午，接收到监控服务器的一条告警短信： 尊敬的运维工程师 XX，你好： “192.168.136.200”数据库服务器 CPU 异常，CPU 使用率 98.7%，请尽快处理。 看到这个消息浑身一紧，赶紧掐灭手中的烟，跑回办公室。 以上段子纯属捏造，如有雷同，我反正是不改。 言归正传，本文是记录一次对达梦数据库的优化过程。 处理问题的第一步，是需要了解当前服务器的状况，我们通过以下两种手段确认服务器瓶颈。 系统状况 通过服务器性能监控大盘观察当前系统性能 通过上图我们看出 CPU 基本耗尽，IO 飙升。 通过 sar 命令观察服务器实时状态 sar 10 3 确认 CPU 被耗满，没有空闲。 通过我的细致观察，发现服务器 CPU 被耗满。接下来需要查看数据库服务器的配置参数是否合理，是否有慢查询脚本。 参数优化 查看 dm 配置文件 cd /dm7/dmdbms/devdb cat dm.ini | grep -E "MEMORY_POOL|MEMORY_TARGET|BUFFER" 发现数据库参数配置为安装时候的默认配置，参数不合理，需要优化参数配置。 备份原配置文件 cp dm.ini dm.ini.bak 修改配置 修改如下几个关键参数，根据之前文章 数据库优化-实例优化 中的表格进行优化（ps：当前数据库内存 2G） 参数 优化建议 优化后的值，单位 M

索引是一个可以提高select查询最有效的手段，可以在数据库中为一列或者多列建立索引，创建索引首先将数据按照从小到大排序，让后存储到存盘中。Mysql中数据存储以页的方式存储，页大小默认16K，存放数据的称之为表页，存放索引的称之为索引页，两者存储角度没有什么区别，但是表页一般相互独立，而索引页之间的关系呈树形结构。 根据树的层级结构划分：根节点、叶子节点、分支节点。叶子结点存储索引列排序后的值，同时存储相邻页的编号和值对应行所在表页的编号，根节点和分支节点主要存储索引列的范围，以及每个范围对应的索引页号。 假设有一个没有索引的表，当要查询表中的某些记录时，需要把所有表页都加载到内存中，在每个表页中筛选出符合的记录以二维表形式返回给用户。若表中的数据量比较大，会有很大的IO开销，而且在筛选数据时CPU的负载也很大，这种方式称之为“全表扫描”。而使用索引时，只需要根据查询范围（前期sql中使用索引）迅速定位到索引表的叶子结点和相关的表页。此期间只需要加载部分索引页和表页即可，减少了IO和CPU的负载，可以很大程度上提高查询效率。但是索引的建立需要审时度势，当表的查询频率比较低，建立索引只会占用磁盘空间，而且索引的空间占用还不小，另外表的数据量大小就更没必要建立索引，总不能书的目录比正文还厚吧，哈哈！ 下面使用一个实验来测试索引对DML语句的影响。首先创建两张表test1，test2：

走zabbix的1.6版本开始测试，1.8的版本开始线上使用，线上使用过1.9、2.0、2.2、3.0、4.0的版本，使用或是测试过zabbix1.6之后的所有版本。个人也有之前的SA转变为DBA，就zabbix的运维走数据库层面有一些自己的心得，希望对读者有所帮助。 1：MySQL版本推荐 MySQL5.7及以上版本，便捷的在线DDL方便zabbix的快速升级 链接数据库方式：zabbix的server、proxy、MySQL数据库尽量使用域名方式连接，方便进行故障切换。 2：zabbix数据库的授权 读写权限，用作zabbix自身访问： grant all privileges on zabbix. to 'zabbix'@'1.1.1.1' identified by 'zabbix'; 只读权限，用作二次开发只读zabbix数据库： grant SELECT on zabbix. to 'zabbix_ro'@'1.1.1.1' identified by 'zabbixro'; 3：MySQL配置文件需要调整的几个重要参数 innodb_log_files_in_group = 16 innodb_log_file_size = 1G innodb_file_per_table = 1 max_allowed_packet = 64M back_log = 1024

1）数据库设计方面 ： a. 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 b. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0 c. 并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时,查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。 d. 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。 e. 应尽可能的避免更新索引数据列，因为索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新索引数据列

数据库查询优化： 1.在表中建立索引，优先考虑where、group by使用到的字段 2.尽量避免使用select *，返回无用的字段会降低查询效率 解决办法：优化方式：使用具体的字段代替*，只返回使用到的字段。 3.尽量避免使用in 和not in，会导致数据库引擎放弃索引进行全表扫描。 优化方式：如果是连续数值，可以用between代替。 如果是子查询，可以用exists代替 4.尽量避免使用or，会导致数据库引擎放弃索引进行全表扫描。 优化方式：可以用union代替or。 5、尽量避免在字段开头模糊查询，会导致数据库引擎放弃索引进行全表扫描。 优化方式：尽量在字段后面使用模糊查询。 6、尽量避免进行null值的判断，会导致数据库引擎放弃索引进行全表扫描。 优化方式：可以给字段添加默认值0，对0值进行判断。 7、尽量避免在where条件中等号的左侧进行表达式、函数操作，会导致数据库引擎放弃索引进行全表扫描。 优化方式：可以将表达式、函数操作移动到等号右侧。 8、当数据量大时，避免使用where 1=1的条件。通常为了方便拼装查询条件，我们会默认使用该条件，数据库引擎会放弃索引进行全表扫描。 优化方式：用代码拼装sql时进行判断，没where加where，有where加and。 来源： CSDN 作者： I_m_Tom 链接： https://blog.csdn.net/Mr

转载自：http://blog.csdn.net/cyjch/article/details/51569377 一、数据量过大，数据中什么情况都可能存在。如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时，前面还能正常处理，突然到了某个地方问题出现了，程序终止了。 二、软硬件要求高，系统资源占用率高。对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。 三、要求很高的处理方法和技巧。这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。 那么处理海量数据有哪些经验和技巧呢，我把我所知道的罗列一下，以供大家参考： 一、选用优秀的数据库工具 现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软公司最近发布的SQL Server 2005性能也不错

一、网站应用背景 开发一个网站的应用程序，当用户规模比较小的时候，使用简单的：一台应用服务器+一台数据库服务器+一台文件服务器，这样的话完全可以解决一部分问题，也可以通过堆硬件的方式来提高网站应用的访问性能，当然，也要考虑成本的问题。 当问题的规模在经济条件下通过堆硬件的方式解决不了的时候，我们应该通过其他的思路去解决问题，互联网发展至今，已经提供了很多成熟的解决方案，但并不是都具有适用性，你把淘宝的技术全部都搬过来也不一定达到现在淘宝的水平，道理很简单。 当然，很多文章都在强调，一个网站的发展水平，是逐渐的演变过来的，并不是一朝一夕的事情。虽然目前的情况互联网的泡沫越来越大，但是整个互联网技术的发展确实为我们提供了方便快捷的上网体验。下边是一张早期的淘宝官网的界面： 目前，博主正在跟随导师做一个创业项目，使用的技术是SSM+MySQL+Linux这些，但是由于资金的限制和考虑到用户群体的特殊性，系统的架构无奈的选择的就是最简单的方式：一台应用服务器、一台数据库服务器、一台文件系统服务器，没有用到高级的技术，也没有用到分布式部署的方案。下边整理的是一些针对海量数据和高并发情况下的解决方案，技术水平有限，欢迎留言指导。 二、针对海量数据和高并发的主要解决方案 2.1、海量数据的解决方案： 使用缓存； 页面静态化技术； 数据库优化； 分离数据库中活跃的数据； 批量读取和延迟修改；

CREATE TABLE IF NOT EXISTS `table1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1; CREATE TABLE IF NOT EXISTS `table2` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1; INSERT INTO `table1` (`name`) VALUES('name1'); INSERT INTO `table2` (`name`) VALUES('name2'); CREATE TABLE IF NOT EXISTS `uTable` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, INDEX(id) ) ENGINE=MRG_MyISAM

mysql数据库架构设计与优化 2019-04-23 20:51:20 无畏D尘埃 阅读数 179 收藏 更多 分类专栏： MySQL 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/qq_37735385/article/details/89480900 数据库设计规范 数据库设计规范 1. 数据库命名规范 2. 数据库基本设计规范 3. 数据库索引设计规范 4. 数据库字段设计规范 5. sql开发规范 6. 数据库操作规范 其他 以上所有规范并非完全不能违背，只是如果不符时，要和公司dba团队确认是否可以做相关操作 数据库设计规范 1. 数据库命名规范 所有数据库对象名称必须使用小写字母并用下划线分隔 mysql是大小写敏感的，sql除外。不同的数据库名：Dbname、dbname；不同的表名：Table、table 所有数据库对象名称，禁止使用mysql保留关键字 比如以下，查询的列表中有from关键字，必须用反单引号转义才行，否则会报错！ select id,username,`from`,age from tb_user; 常见的mysql关键字 数据库对象的命名要能做到见名知意，并且最好不要超过32个字符 例如：用户账号表 user_account

补充：负载均衡和读写分离楼主并没有尝试使用过，这里作为学习笔记，有些只是概念性的理解一下，后续补充具体案例及使用方法介绍 负载均衡 概念 多个服务器的数据库完成一个服务器数据库的事 ( 数据库必须保持一致性 ) 利用多台服务器的读写能力，但是数据同步和访问分配交给第三方，读的压力分摊到不同的 服务器，写时多台服务器都得完成，对外只有一个 IP ，使用者是不知道细节的 读写分离 概念 基于二八原则： 80% 的操作都是读， 20%s 写。实现原理：就是把读和写的眼里分开，降低 IO 压力 一主多从，主库写从库读。数据同步，从主库到从库 ( 肯定是有延迟的 ) 四种读写分离方式 1 Link 到主库 + 定时任务 2 日志传送 (sql2005) 实现原理：备份 -- 复制 -- 恢复，简单但是有局限性 ( 局域网，只能文件夹共享 ) 3 镜像 snapshot ：内存拍照 主库，对外提供服务。 从库，通过快照恢复，数据跟主库一致 ( 不对外提供服务 ) 监控转移，负责检查状况，有问题切到从库 4 数据复制 ( 发布订阅 ) 主库 -- 发布服务器 -- 从库 延迟小，配置方便，但是需要程序配合 实现方式参考 ： https://blog.csdn.net/u012861467/article/details/76411216 https://blog.csdn.net/qq