数据库数据如何备份(数据备份策略)
- 冷备份:定期将数据库中的文件进行转储,定期进行数据备份.
- 热备份:搭建数据库主从结构,当主库数据发生改变时,从库根据主库的二进制日志
文件进行备份. - 双机热备:数据库互为主从,数据库代理服务器对主库进行心跳检测,实现数据的高
可用,为了防止主库宕机后发生雪崩现象
数据库压力大时,怎么实现高可用
1.用数据库代理服务器搭建数据库的读写分离进行分流.读取从库数据,写数据在主库
可用的数据库代理服务器有 Amoeba 和 Mycat
由于大量的用户的数据库操作都需要通过数据库来完成.造成数据库负载过高.因为数
据库操作中查询的操作占很大的比重.
2.数据库实现双机热备.
数据库的优化策略
- 优化 sql 语句(多表操作) where 左连接 右连接 内连接
原则:尽可能根据主键查询,尽可能少用关联查询. - 创建索引(对经常查询的数据创建索引)
- 添加缓存(Redis/MemCache)
- 定期进行数据转储(将一些查询较少的数据保存到历史表,让当前表维护可控的数
据量) - 分库分表(需要大量的数据库服务器)
Mysql 数据库优化
(1)查询时，能不用* 就不用，尽量写全字段名。
(2)索引不是越多越好，每个表控制在 6 个索引以内。范围 where 条件的情况下，索引不起
作用，比如 where value<100
(3)大部分情况连接效率远大于子查询，但是有例外。当你对连接查询的效率都感到不能接
受的时候可以试试用子查询，虽然大部分情况下你会更失望，但总有碰到惊喜的时候不是
么…
(4)多用 explain 和 profile 分析查询语句
(5)有时候可以 1 条大的 SQL 可以分成几个小 SQL 顺序执行，分了吧，速度会快很多。
(6)每隔一段时间用 alter table table_name engine=innodb;优化表
(7)连接时注意:小表 jion 大表的原则
(8)学会用 explain 和 profile 判断是什么原因使你的 SQL 慢
(9)查看慢查询日志，找出执行时间长的 SQL 进行优化
(10)尽量避免使用 order by
(11)因为 where 子句后面的条件是执行顺序是从右到左，所以尽量把能过滤掉大部分数据
的条件放在最后
数据库有几种隔离级别
1、Serializable (串行化)：可避免脏读、不可重复读、幻读的发生
2、Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
3、Read committed (读已提交)：可避免脏读的发生。
4、Read uncommitted (读未提交)：最低级别，任何情况都无法保证
sql 优化：（索引、范式）
三范式：
第一范式（确保每列保持原子性）最基本范式。数据库表中所有字段值都是不可分解的
原子值，就满足了第一范式。
第二范式（确保表中的每列都和主键相关）在第一范式上更近一层。确保数据库表中的每一
列都和主键相关，而不能只与主键的某一部分相关，也就是说一个表中只能保存一种数据，
不可以吧多种数据保存在一张表中。
第三范式：确保每列都和主键列直接相关，不是间接相关。
索引：
避免对索引字段进行计算、避免索引在字段上使用 not、<>、！=、避免在索引上使用
IS NULL 和 NOT NULL、避免在索引列上出现数据类型转换、避免索引字段使用函数、避
免建立索引的列出现空值
SQL 优化
- SELECT 子句中避免使用‘*’
- SQL 语句用大写的
- 用 IN 来替换 OR
- 查询语句中不要使用 *
- 尽量减少子查询，使用关联查询（left join,right join,inner join）替代
- 减少使用 IN 或者 NOT IN ,使用 exists，not exists 或者关联查询语句替代
- or 的查询尽量用 union 或者 union all 代替
- 合理的增加冗余的字段（减少表的联接查询）
- 增加中间表进行优化（这个主要是在统计报表的场景，
性能优化
表的设计合理化，符合三大范式（3NF)
1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足1NF)
2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
3NF是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。
添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引]
较频繁的作为查询条件字段应该创建索引；
唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件；
更新非常频繁的字段不适合创建索引
不会出现在WHERE子句中的字段不该创建索引
分表技术(水平分割、垂直分割)；
读写[写: update/delete/add]分离；
存储过程 [模块化编程，可以提高速度]；
对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ]；
mysql服务器硬件升级；
定时的去清除不需要的数据,定时进行碎片整理(MyISAM)。
SQL语句优化
通过show status命令了解各种SQL的执行频率；
定位执行效率较低的SQL语句-（重点select；
通过explain分析低效率的SQL；
确定问题并采取相应的优化措施。
优化
1、选取最适用的字段属性
MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。
例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。
另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOTNULL，这样在将来执行查询的时候，数据库不用去比较NULL值。
对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。
2、使用连接（JOIN）来代替子查询(Sub-Queries)
MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：
DELETE FROM customerinfo
WHERE CustomerID NOT IN (SELECT CustomerID FROM salesinfo)
使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接（JOIN）…替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：
SELECT * FROM customerinfo
WHERE CustomerID NOT IN (SELECTC ustomerID FROM salesinfo)
如果使用连接（JOIN）…来完成这个查询工作，速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：
SELECT * FROM customerinfo
LEFT JOIN salesinfo ON customerinfo.CustomerID=salesinfo.CustomerID
WHERE salesinfo.CustomerID ISNULL
连接（JOIN）…之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。
3、使用联合(UNION)来代替手动创建的临时表
MySQL从4.0的版本开始支持union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用union来创建查询的时候，我们只需要用UNION作为关键字把多个select语句连接起来就可以了，要注意的是所有select语句中的字段数目要想同。下面的例子就演示了一个使用UNION的查询。
SELECT Name,Phone FROM client UNION
SELECT Name,BirthDate FROM author UNION
SELECT Name,Supplier FROM product
优化方向
- SQL以及索引的优化
首先要根据需求写出结构良好的SQL，然后根据SQL在表中建立有效的索引。但是如果索引太多，不但会影响写入的效率，对查询也有一定的影响。 - 合理的数据库是设计
根据数据库三范式来进行表结构的设计。设计表结构时，就需要考虑如何设计才能更有效的查询。
数据库三范式：
第一范式：数据表中每个字段都必须是不可拆分的最小单元，也就是确保每一列的原子性；
第二范式：满足一范式后，表中每一列必须有唯一性，都必须依赖于主键；
第三范式：满足二范式后，表中的每一列只与主键直接相关而不是间接相关(外键也是直接相关)，字段没有冗余。
注意：没有最好的设计，只有最合适的设计，所以不要过分注重理论。三范式可以作为一个基本依据，不要生搬硬套。
有时候可以根据场景合理地反规范化：
A：分割表。
B：保留冗余字段。当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的字段，以 避免表之间的连接过于频繁，一般在冗余列的数据不经常变动的情况下使用。
C：增加派生列。派生列是由表中的其它多个列的计算所得，增加派生列可以减少统计运算，在数据汇总时可以大大缩短运算时间。
数据库五大约束：
A：PRIMARY key:设置主键约束；
B：UNIQUE：设置唯一性约束，不能有重复值；
C：DEFAULT 默认值约束
D：NOT NULL：设置非空约束，该字段不能为空；
E：FOREIGN key :设置外键约束。
字段类型选择：
A：尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED
B：VARCHAR的长度只分配真正需要的空间
C：使用枚举或整数代替字符串类型
D：尽量使用TIMESTAMP而非DATETIME
E：单表不要有太多字段，建议在20以内
F：避免使用NULL字段，很难查询优化且占用额外索引空间
异步/多线程
针对某些客户端的请求，在服务端可能需要针对这些请求做一些附属的事情，这些事情其实用户并不关心或者用户不需要立即拿到这些事情的处理结果，这种情况就比较适合用异步的方式处理这些事情。
异步作用
A：缩短接口响应时间，使用户的请求快速返回，用户体验更好。
B：避免线程长时间处于运行状态，这样会引起服务线程池的可用线程长时间不够用，进而引起线程池任务队列长度增大，从而阻塞更多请求任务，使得更多请求得不到技术处理。
C：线程长时间处于运行状态，可能还会引起系统Load、CPU使用率、机器整体性能下降等一系列问题，甚至引发雪崩。异步的思路可以在不增加机器数和CPU数的情况下，有效解决这个问题。
异步实现
A：额外开辟线程，这里可以采用额外开辟一个线程或者使用线程池的做法，在IO线程（处理请求响应）之外的线程来处理相应的任务，在IO线程中让response先返回。
B：使用消息队列（MQ）中间件服务
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
