10-04 16—20
16. 简述触发器、函数、视图、存储过程？
触发器：触发器是一个特殊的存储过程，它是MySQL在insert、update、delete的时候自动执行的代码块。
create trigger trigger_name
after/before insert /update/delete on 表名
for each row
begin
sql语句：（触发的语句一句或多句）
end
函数：MySQL中提供了许多内置函数，还可以自定义函数（实现程序员需要sql逻辑处理）
自定义函数创建语法：
创建：CREATE FUNCTION 函数名称(参数列表)
RETURNS 返回值类型 函数体
修改：ALTER FUNCTION 函数名称 [characteristic ...]
删除：DROP FUNCTION [IF EXISTS] 函数名称
调用：SELECT 函数名称(参数列表)
视图：视图是由查询结果形成的一张虚拟表，是表通过某种运算得到的一个投影
create view view_name as select 语句
存储过程：把一段代码封装起来，当要执行这一段代码的时候，
可以通过调用该存储过程来实现（经过第一次编译后再次调用不需要再次编译，比一个个执行sql语句效率高）
create procedure 存储过程名(参数,参数,…)
begin
//代码
end
17. 列举 创建索引但是无法命中索引的8种情况。
- 1、如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因）
- 2、对于多列索引，不是使用的第一部分(第一个)，则不会使用索引
- 3、like查询是以%开头
- 4、如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
- 5、如果mysql估计使用全表扫描要比使用索引快,则不使用索引
- 6 对小表查询
- 7 提示不使用索引
- 8 统计数据不真实
- 9.单独引用复合索引里非第一位置的索引列.
18. 优化数据库？提高数据库的性能
- 对语句的优化
①用程序中，保证在实现功能的基础上，尽量减少对数据库的访问次数；
通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；
②能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；
③在查询时，不要过多地使用通配符如 SELECT * FROM T1 语句，要用到几列就选择几列如：
SELECT COL1,COL2 FROM T1；
④在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。
⑤不要在应用中使用数据库游标，游标是非常有用的工具，但比使用常规的、面向集的SQL语句需要更大的开销；按照特定顺序提取数据的查找。 - 避免使用不兼容的数据类型
例如float和int、char和varchar、binary 和varbinary是不兼容的。
数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。
例如:
SELECT name FROM employee WHERE salary ＞ 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000 是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。 若在查询时强制转换，查询速度会明显减慢。 - 避免在WHERE子句中对字段进行函数或表达式操作。
若进行函数或表达式操作，将导致引擎放弃使用索引而进行全表扫描。 - 避免使用!=或＜＞、IS NULL或IS NOT NULL、IN ，NOT IN等这样的操作符
- 尽量使用数字型字段
- 合理使用EXISTS,NOT EXISTS子句。
- 尽量避免在索引过的字符数据中，使用非打头字母搜索。
- 分利用连接条件
- 消除对大型表行数据的顺序存取
- 避免困难的正规表达式
- 使用视图加速查询
- 能够用BETWEEN的就不要用IN
- DISTINCT的就不用GROUP BY
- 部分利用索引
- 能用UNION ALL就不要用UNION
- 不要写一些不做任何事的查询
- 尽量不要用SELECT INTO语句
- 必要时强制查询优化器使用某个索引
- 虽然UPDATE、DELETE语句的写法基本固定，但是还是对UPDATE语句给点建议：
a) 尽量不要修改主键字段。
b) 当修改VARCHAR型字段时，尽量使用相同长度内容的值代替。
c) 尽量最小化对于含有UPDATE触发器的表的UPDATE操作。
d) 避免UPDATE将要复制到其他数据库的列。
e) 避免UPDATE建有很多索引的列。
f) 避免UPDATE在WHERE子句条件中的列。
19. 数据库负载均衡
负载均衡集群是由一组相互独立的计算机系统构成，通过常规网络或专用网络进行连接，由路由器衔接在一起，各节点相互协作、共同负载、均衡压力，对客户端来说，整个群集可以视为一台具有超高性能的独立服务器。
1、 实现原理
实现数据库的负载均衡技术，首先要有一个可以控制连接数据库的控制端。在这里，它截断了数据库和程序的直接连接，由所有的程序来访问这个中间层，然后再由中间层来访问数据库。这样，我们就可以具体控制访问某个数据库了，然后还可以根据数据库的当前负载采取有效的均衡策略，来调整每次连接到哪个数据库。
2、 实现多据库数据同步
对于负载均衡，最重要的就是所有服务器的数据都是实时同步的。这是一个集群所必需的，因为，如果数不据实时、不同步，那么用户从一台服务器读出的数据，就有别于从另一台服务器读出的数据，这是不能允许的。所以必须实现数据库的数据同步。这样，在查询的时候就可以有多个资源，实现均衡。比较常用的方法是Moebius for SQL Server集群，Moebius for SQL Server集群
采用将核心程序驻留在每个机器的数据库中的办法，这个核心程序称为Moebius for SQL Server 中间件，主要作用是监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。正因为Moebius 中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。
数据条数很少，数据内容也不大，则直接同步数据。数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。 数据条数很多，此时中间件会拿到造成数据变化的SQL语句， 然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用。
3、 优缺点
优点：
- 扩展性强：当系统要更高数据库处理速度时，只要简单地增加数据库服务器就 可以得到扩展。
- 可维护性：当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作。
- 安全性：因为数据会同步的多台服务器上，可以实现数据集的冗余，通过多份数据来保证安全性。另外它成功地将数据库放到了内网之中，更好地保护了数据库的安全性。
- 易用性：对应用来说完全透明，集群暴露出来的就是一个IP
缺点：
a) 不能够按照Web服务器的处理能力分配负载。
b) 负载均衡器(控制端)故障，会导致整个数据库系统瘫痪。
20. 数据库三大范式？
什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些 规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。
什么是三大范式：
第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。
第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。
第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF.
注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性
