数据库性能

hbase是列数据库，是kv结构的，ES的基于Lucene的搜索引擎的面向文档数据库吧 ES是搜索引擎，主要的优势在于快速搜索，HBase是数据库，优势在于存储数据，侧重点不同 MySQL：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group Replication架构模型（本文全部以Innodb为例，不涉及别的存储引擎）。 HBase：基于HDFS，支持海量数据读写（尤其是写），支持上亿行、上百万列的，面向列的分布式NoSql数据库。天然分布式，主从架构，不支持事务，不支持二级索引，不支持sql。 ElasticSearch：ES是一款分布式的全文检索框架，底层基于Lucene实现，虽然ES也提供存储，检索功能，但我一直不认为ES是一款数据库，但是随着ES功能越来越强大，与数据库的界限也越来越模糊。天然分布式，p2p架构，不支持事务，采用倒排索引提供全文检索。 数据存储方式 假设有这样一张人员信息表： MySQL中要提前定义表结构，也就是说表共有多少列（属性）需要提前定义好，并且同时需要定义好每个列所占用的存储空间。数据以行为单位组织在一起的，假如某一行的某一列没有数据，也需要占用存储空间。 HBase则是以列为单位存储数据，每一列就是一个key-value，HBase的表列（属性）不用提前定义，而且列可以动态扩展

一、百万级数据库优化方案 1.对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库. 备注、描述、评论之类的可以设置为 NULL，其他的，最好不要使用NULL。 不要以为 NULL 不需要空间，比如：char(100) 型，在字段建立时，空间就固定了， 不管是否插入值（NULL也包含在内），都是占用 100个字符的空间的，如果是varchar这样的变长字段， null 不占用空间。 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num = 0 3.应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or Name = 'admin' 可以这样查询：

作者: 听风，原文地址: https://www.cnblogs.com/huchong/p/10219318.html 。JavaGuide 已获得作者授权。 数据库命令规范 数据库基本设计规范 1. 所有表必须使用 Innodb 存储引擎 2. 数据库和表的字符集统一使用 UTF8 3. 所有表和字段都需要添加注释 4. 尽量控制单表数据量的大小,建议控制在 500 万以内。 5. 谨慎使用 MySQL 分区表 6.尽量做到冷热数据分离,减小表的宽度 7. 禁止在表中建立预留字段 8. 禁止在数据库中存储图片,文件等大的二进制数据 9. 禁止在线上做数据库压力测试 10. 禁止从开发环境,测试环境直接连接生成环境数据库 数据库字段设计规范 1. 优先选择符合存储需要的最小的数据类型 2. 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据 3. 避免使用 ENUM 类型 4. 尽可能把所有列定义为 NOT NULL 5. 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间 6. 同财务相关的金额类数据必须使用 decimal 类型 索引设计规范 1. 限制每张表上的索引数量,建议单张表索引不超过 5 个 2. 禁止给表中的每一列都建立单独的索引 3. 每个 Innodb 表必须有个主键 4.

MySQL性能 最大数据量 最大并发数 查询耗时0.5秒 实施原则 数据表设计 数据类型 避免空值 text类型 索引优化 索引分类 优化原则 SQL优化 分批处理 不做列运算 避免Select * 操作符<>优化 OR优化 IN优化 LIKE优化 JOIN优化 LIMIT优化 其他数据库   博主负责的项目主要采用阿里云数据库MySQL，最近频繁出现慢SQL告警，执行时间最长的竟然高达5分钟。导出日志后分析，主要原因竟然是 没有命中索引和没有分页处理 。其实这是非常低级的错误，我不禁后背一凉，团队成员的技术水平亟待提高啊。改造这些SQL的过程中，总结了一些经验分享给大家，如果有错误欢迎批评指正。 MySQL性能 最大数据量    抛开数据量和并发数，谈性能都是耍流氓 。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。 文件系统 单文件大小限制 FAT32 最大4G NTFS 最大64GB NTFS5.0 最大2TB EXT2 块大小为1024字节，文件最大容量16GB；块大小为4096字节，文件最大容量2TB EXT3 块大小为4KB，文件最大容量为4TB EXT4 理论可以大于16TB 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才推荐分库分表。性能由综合因素决定，抛开业务复杂度，影响程度依次是硬件配置、MySQL配置

传统的数据库连接方式 一个连接对象对应一个物理连接，每次操作都打开一个物理连接，使用完都关闭连接，造成系统性能低下。 连接池技术 客户程序得到的连接对象是连接池中物理连接的一个句柄，调用连接对象的close()方法,物理连接并没有关闭,数据源的实现只是删除了客户程序中的连接对象和池中的连接对象之间的联系. 数据库连接的建立及关闭是耗费系统资源的操作，在大型应用中对系统的性能影响尤为明显。为了能重复利用数据库连接对象,缩短请求的响应时间和提高服务器的性能,支持更多的客户，应采用连接池技术. 来源： https://www.cnblogs.com/Yanss/p/11739073.html

一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销

作者 | 惨绿少年 链接 | https://clsn.io/clsn/lx287.html 一、前言 MySQL调优对于很多程序员而言，都是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。 今天给大家讲解MySQL的优化实战，助你高薪之路顺畅！ 图片描述(最多50字) 二、优化的哲学 注意：优化有风险，涉足需谨慎！ 1、优化可能带来的问题 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。 保持现状或出现更差的情况都是失败！ 2、优化的需求 稳定性和业务可持续性,通常比性能更重要！ 优化不可避免涉及到变更，变更就有风险！ 优化使性能变好，维持和变差是等概率事件！ 切记优化,应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！ 所以优化工作,是由业务需要驱使的！！！ 3、优化由谁参与 在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员

这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息 mysql在遇到严重性能问题时，一般都有这么几种可能： 1、索引没有建好; 2、sql写法过于复杂; 3、配置错误; 4、机器实在负荷不了; 1、索引没有建好 如果看到mysql消耗的cpu很大，可以用mysql的client工具来检查。 在linux下执行 /usr/local/mysql/bin/mysql -hlocalhost -uroot -p 输入密码，如果没有密码，则不用-p参数就可以进到客户端界面中。 看看当前的运行情况 show full processlist 可以多运行几次 这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息 在我的cache后端，这里面大部分时间是看不到显示任何sql语句的，我认为这样才算比较正常。如果看到有很多sql语句，那么这台mysql就一定会有性能问题 如果出现了性能问题，则可以进行分析： 1、是不是有sql语句卡住了? 这是出现比较多的情况，如果数据库是采用myisam，那么有可能有一个写入的线程会把数据表给锁定了，如果这条语句不结束，则其它语句也无法运行。 查看processlist里的time这一项

单独的数据库： 微服务设计的一个关键是数据库设计，基本原则是每个服务都有自己单独的数据库，而且只有微服务本身可以访问这个数据库。它是基于下面三个原因。 优化服务接口：微服务之间的接口越小越好，最好只有服务调用接口（RPC或消息），没有其他接口。如果微服务不能独享自己的数据库，那么数据库也变成了接口的一部分，这大大拓展了接口范围。 错误诊断：生产环境中的错误大部分都是和数据库有关的，要么是数据出了问题，要么是数据库的使用方式出了问题。当你不能完全控制数据库的访问时，会有各种各样的错误发生。它可能是别的程序直接连到你的数据库或者是其他部门直接用客户端访问数据库的数据，而这些都是在程序中查不到的，增加了错误排查难度。如果是程序中的问题，只要修改了代码，那么这个错误就不会再有。而上面提到的错误，你永远都没法预测它们什么时候还会再次发生。 性能调优：性能调优也是一样，你需要对数据库有全权控制才能保证它的性能。如果其他部门一定要访问数据库，而且只是查询的话，那么可以另外创建一份只读数据库，让他们在另一个库中查询，这样才不会影响到你的库。 理想的设计是你的数据库只有你的服务能访问，你也只调用自己数据库中的数据，所有对别的微服务的访问都通过服务调用来实现（请参阅“微服务之间调用的最佳设计“）。当然，在实际应用中，单纯的服务调用可能不能满足性能或其他要求，不同的微服务都多少需要共享一些数据。

性能测试分类 性能测试是一个非常广泛的概念，包括很多方面的测试，也可称之为非功能测试。 移动端性能测试（耗电量、稳定性、弱信号、空数据） 自动化测试属于功能测试的范围，由于其测试方法要求测试人员拥有一定的代码能力，所以被单独分成一个测试模块 具体分类（测试范围） 　　1、负载测试：通过逐步加压的方法，达到既定的性能阈值的目标，阈值的设定应是小于等于某个值，如cpu使用率小于等于80% 　　2、压力测试：通过逐步加压的方法，使得系统的某些资源达到饱和，甚至失效的状态，简单粗暴的解释就是什么条件能把系统压崩溃。 　　3、并发测试：在同一时间内，多个虚拟用户同时访问同一模块、同一功能，通常的测试方法是设置集合点。 　　4、容量测试：通常是指数据库层面的，目标是获取数据库的最佳容量的能力。又称之为容量预估。具体测试方法为在一定的并发用户，不同的基数数据量下，观察数据库的处理能力，即获取数据库的各项性能指标。（如压测100个用户，数据库一个表有500、1000条数据，同样的并发用户，结果是不一样的） 　　5、可靠性测试：又称之为稳定性测试或疲劳测试。是指系统在高压情况下，长时间的运行系统是否稳定。如cpu使用率在80%以上，7*24小时运行，系统是否稳定。（最能发现内存溢出） 　　6、异常测试：又称之为失败测试。是指系统架构方面的测试。如在负载均衡架构中，要测试宕机、节点挂掉等情况系统的反映