数据库优化

数据库的基本语法的使用，很多，我也没有去整理，所以在这里就不介绍那些基本的语法了。如果对这方面有问题，我在这里给大家分享一个方法： 　　SQL语句应该怎样去优化？在职业生涯中，有一次维护一个项目中的一个模块。之前做的那个同事离职了，交给我来维护。我记得好像是七八张表吧，各种join、order by、distinct、group by.......看得头大。这样的SQL语句应该怎么优化呢？额......这怎么优化啊？建议从表的设计方面考虑吧。后来我也是这样做的，重新设计表，将表的数量减少，将数据更新到那写新表中去。即使不刷数据，流程中做下控制，时间久了，老表中的数据也都会更新到新表中去。 数据库设计步骤： 　　1、需求分析：大概明白需要存储什么 　　2、概要设计阶段：E-R图，表-属性-关系表，解决多方的沟通问题 　　3、详细设计，细致到表甚至字段 关系型数据库：面向对象的封装+关系 面向对象的思想来建表： 　　一对一：人----身份证；垂直分别的时候；相同主键/外键 　　一对多：订单----商品表；省-----市；公司-----员工；主外键表示 　　多对多：用户----菜单；学生----课程；女神----备胎；关系表/中间/映射表 三大范式： 　　第一范式：每一列保持原子性，不可分割 　　　　原子性：不可分割。 　　　　人----工作电话/家庭电话/移动电话，必须要拆分开

ETL效率优化 开启数据库日志记录及性能监控 如果我们想要优化一个ETL（KTR或者KJB）的性能，我们首先需要知道的就是它的瓶颈在哪里。而这些信息一般只能在ETL运行的步骤度量中看到，并且是不会持久化的。如果你希望把一些数据记录下来，帮助以后进行查阅，那么可以开启数据库日志和性能监控。 作业 Edit -> Settings -> Log 具体设置过程就不细讲了，很简单。 转化 Edit -> Settings -> Logging 这时开启了日志记录，还需要设置性能监控 Edit -> Settings -> Monitoring 勾选 Enable step performance monitoring（开启性能监控），下面的两个选项分别是： Step performance measurement interval ( ms ) (对每一步进行性能监测的度量间隔)：这一个选项的大小会影响你在数据库记录的详细程度，一般以运行总时长的十分之一左右的数值即可，这样对于每一步可以记录 10 组左右的数据，足够做一些基本的分析，注意单位是毫秒。 Maximum number of snapshots in memory （在内存中保存的最大的快照数量）：这一个选项在我们系统的内存不是很足够时可以使用，但是太小可能会导致无法分析出来，和上面的选项搭配使用。 转化的错误日志输出

一、数据库性能瓶颈主要原因 1、数据库连接 MySQL数据库默认连接为100，我们可以通过配置initialSize、minIdle、maxActive等进行调优，但由于硬件资源的限制，数据库连接不可能无限制的增加，对大型单体应用单实例数据库可能会出现最大连接数不能满足实际需求的情况，这时就会系统业务阻塞。 2、表数据量大（空间存储问题） 普遍观点认为单表数据量超过1000万条时就是出现数据库读取性能瓶颈。从索引角度分析，如果索引未被命中，数据库系统就会全表扫描，数据量越大，扫描全表的时间就会越长；即使索引被命中了，由于B+TREE索引是存放在硬盘上的，数据量越大B+TREE层次越深，IO次数也就越多。 3、硬件资源限制 硬件资源直接影响QPS每秒查询数/TPS每秒事务数。 二、数据性能优化方案 常见的数据性能优化方案：SQL优化、缓存、创建索引、读写分离、分库分表等。 解决大数据量性能优化，真正有效方案是采用分布式数据存储，即上面所述读写分离和分库分表。 1、读写分离 读写分离基于主从复制，采用区别读、写多数据源方式进行数据的存储和加载。数据的存储（增删改）指定写数据源，数据的读取查询指定读数据源。 通过读写分离复制与master相同的数据源（一主多从），多数据源可以部署到不同主机上，从而可以解决数据里连接瓶颈和硬件资源限制问题。 2、分库分表 对数据的库表进行拆分

不要在循环里面查询数据库因为查询数据库要通过url建立连接，初始化，获取连接池，再把资源放回连接池，关闭等操作，十分的消耗资源。如果在循环里面查询数据库，就会出现频繁的进行上面的那些操作，就会消耗掉大量的资源。会导致延迟，卡死，等待等诸多状况。所以尽量不要在循环里面查数据库。 在数据库的properties里面存储的是一些URL，地址等一些final static（最终的，不会改变的常量）的信息。当项目中需要某些信息，但是这些信息是固定的常量，不会改变。比如一些URL地址，请求头信息等。我们一般的想法是设置成final static放在工具类中，但其实在项目中如果这样做，一是显得代码比较散乱。二是维护起来比较麻烦，每次还要打开程序，进入到工具类中进行修改。一般都放在数据库中。需要时提前查出来这些信息就可以使用，当需要修改的时候，直接修改数据库就可以了，比较便捷，利于维护

Mysql sql 一. 正则表达式 二. 查询 1. show status 这次登录以来操作多少次 Show status like ‘com_insert%’ Show status like ‘com_update%’ Show status like ‘com_select%’ Show status like ‘com_delete%’ 2. show status like 'innodb_rows%' 数据库历史操作以来增删改查的影响行数 3. show status like 'connections%' Mysql , , 三. Mysql 1. , 2. , ( , ) 3. like, Like “%l”, Like “%l%”, 4. or union all Or Union all Select * from user where name=’a’ union all select * from user where age=’20’ 5. . :Where truncate(price)=1 :where price>1 and price<2 6. ,不加索引,数字加上引号转为字符串,加索引 Where tel=12345678901 不加索引 Where tel=’12345678901’加索引 7. ,加索引 Select * from

数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我 们程序员需要去关注的事情 1.为查询缓存优化你的查询 mysql > show variables like ' %query_cache% ' ; （query_cache_type 为 ON 表示已经开启） + -- ----------------------------+----------+ | Variable_name | Value | + -- ----------------------------+----------+ | have_query_cache | YES | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 20971520 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | + -- ----------------------------+----------+ 如果不是ON，修改配置文件以开启查询缓存： > vi / etc / my.cnf [ mysqld ] 中添加： query_cache

MySQL数据库优化: mysql表复制: 第一步：1.复制表结构 create table student like user; 第二步：2.复制表内容 insert into student select * from user; mysql索引: 1.查看索引 show index from user\G 2.普通索引 1)创建 create index i_age on user(age); 2)删除 drop index i_age on user; 3.唯一索引 1)创建 create unique index u_username on user(username); 2)删除 drop index u_username on user; mysql视图: 1.创建 create view userclass as select user.username,user.age,class.name from user,class where user.class_id=class.id; 2.删除 drop view userclass; 3.查看 show tables; 4.查看视频数据 select * from userclass; 5.视图的特性 当表中数据发生变化时视图数据也会随着发生变化. mysql中查看表中未来的自增数: show create

1. 如何设计一个高并发的系统 ① 数据库的优化，包括合理的事务隔离级别、SQL语句优化、索引的优化 ② 使用缓存，尽量减少数据库 IO ③ 分布式数据库、分布式缓存 ④ 服务器的负载均衡 2. 锁的优化策略 ① 读写分离 ② 分段加锁 ③ 减少锁持有的时间 ④ 多个线程尽量以相同的顺序去获取资源 等等，这些都不是绝对原则，都要根据情况，比如不能将锁的粒度过于细化，不然可能会出现线程的加锁和释放次数过多，反而效率不如一次加一把大锁。这部分跟面试官谈了很久 3. 索引的底层实现原理和优化 B+树，经过优化的B+树 主要是在所有的叶子结点中增加了指向下一个叶子节点的指针，因此InnoDB建议为大部分表使用默认自增的主键作为主索引。 ① 以“%”开头的LIKE语句，模糊匹配 ② OR语句前后没有同时使用索引 ③ 数据类型出现隐式转化（如varchar不加单引号的话可能会自动转换为int型） order by要怎么处理 alter尽量将多次合并为一次 insert和delete也需要合并 等等 6. 实践中如何优化MySQL 我当时是按以下四条依次回答的，他们四条从效果上第一条影响最大，后面越来越小。 ① SQL语句及索引的优化 ② 数据库表结构的优化 ③ 系统配置的优化 ④ 硬件的优化 变种极多，攻击简单，危害极大 未经授权操作数据库的数据 恶意纂改网页

数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。 查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询*作。经验告诉我们，在优化查询时，必须做到： ① 尽可能少的行； ② 避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中*作；用简单的键（列）排序，如整型或短字符串排序； ③ 避免表内的相关子查询； ④ 避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符串连接； ⑤ 在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接； ⑥ 利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。 除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序。 分割表或储存冗余数据 分割表分为水平分割表和垂直分割表两种。分割表增加了维护数据完整性的代价。 水平分割表：一种是当多个过程频繁访问数据表的不同行时，水平分割表，并消除新表中的冗余数据列；若个别过程要访问整个数据，则要用连接*作，这也无妨分 割表；典型案例是电信话单按月分割存放。另一种是当主要过程要重复访问部分行时，最好将被重复访问的这些行单独形成子集表（冗余储存），这在不考虑磁盘空

一、百万级数据库优化方案 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' 可以这样查询：