MySQL必知必会随笔

个人随笔记录 若有哪些写的不对欢迎批评指正

mysql 不区分大小写 以后代码里要注意写sql时 关键字 大写,其余小写
IN操作符一般比OR操作符清单执行更快。
mysql 对于正则表达式转义字符是两个斜杠 \
，SELECT Trim(‘abc’);将返回abc 用于实验 ,省略from后面.

时间操作时要记得使用Date()函数 这是一个良好习惯

如:
sql1 :SELECT * FROM a WHERE addtime = ‘2020-04-06’
上面sql1写法并不规范 因为addtime后默认还有00:00:00 不能精确匹配 正确sql如sql2:
sql2: SELECT * FROM a WHERE DATE(addtime) = ‘2020-04-26’

注意sum()函数的null值问题 sum(price1+price2) 若price2变量传入的是null值 代码报错

group by 实际开发中总难免用错 故截取:

因为使用了GROUP BY，就不必指定要计算和估值的每个组了。系统 会自动完成。GROUP BY子句指示MySQL分组数据，然后对每个组而不是 整个结果集进行聚集。 在具体使用GROUP BY子句前，需要知道一些重要的规定。
GROUP BY子句可以包含任意数目的列。这使得能对分组进行嵌套， 为数据分组提供更细致的控制。
如果在GROUP BY子句中嵌套了分组，数据将在后规定的分组上 进行汇总。换句话说，在建立分组时，指定的所有列都一起计算 （所以不能从个别的列取回数据）。
GROUP BY子句中列出的每个列都必须是检索列或有效的表达式 （但不能是聚集函数）。如果在SELECT中使用表达式，则必须在 GROUP BY子句中指定相同的表达式。不能使用别名。
除聚集计算语句外，SELECT语句中的每个列都必须在GROUP BY子 句中给出。
如果分组列中具有NULL值，则NULL将作为一个分组返回。如果列 中有多行NULL值，它们将分为一组。 GROUP BY子句必须出现在WHERE子句之后，ORDER BY子句之前。

GROUP BY xxx WITH ROLLUP 用于分组后再统计

HAVING和WHERE的差别 :

这里有另一种理解方法，WHERE在数据 分组前进行过滤，HAVING在数据分组后进行过滤。这是一个重要的区别，

插入 修改 删除语句降低优先级保证查询语句性能:

INSERT LOW_PRIORITY INTO

修改语句忽略错误:

UPDATE IGNORE customers

创建表时引擎类型:

InnoDB是一个可靠的事务处理引擎（参见第26章），它不支持全文 本搜索；
MEMORY在功能等同于MyISAM，但由于数据存储在内存（不是磁盘） 中，速度很快（特别适合于临时表）；
MyISAM是一个性能极高的引擎，它支持全文本搜索（参见第18章）， 但不支持事务处理。
其中 引擎可以混用 但是 外键不能跨引擎，即使用一 个引擎的表不能引用具有使用不同引擎的表的外键

视图: 个人理解:为存在数据字典中的一个select 结果集 (理解错误…应该把结果集修改为select语句不知道对不对 因为如下:)
视图仅仅是用来查看存储在别处的数据的一种设施。 视图本身不包含数据，因此它们返回的数据是从其他表中检索出来的
优点:
方便查询,方便管理权限 防止不必要的字典暴露 (mysql 不支持行和列级别的权限控制 所以视图是不二之选),二:简化复杂的SQL操作。在编写查询后，可以方便地重用它而不必 知道它的基本查询细节

视图章节小结总结的挺好的:
视图为虚拟的表。它们包含的不是数据而是根据需要检索数据的查 询。视图提供了一种MySQL的SELECT语句层次的封装，可用来简化数据 处理以及重新格式化基础数据或保护基础数据。

存储过程

个人理解:在mysql中的一个带码(多条sql的一个汇总),通过传参执行存储过程后直接获得结果
优点:简单、安全、高性能
缺点:，存储过程的编写比基本SQL语句复杂,且需要更高权限(编写) 如果你不能编写 你仍然可以使用其他人编写的存储过程

触发器

保持每个数据库的触发器名唯一
触发器仅支持表

最后 节选改善性能章节

**** 首先，MySQL（与所有DBMS一样）具有特定的硬件建议。在学 习和研究MySQL时，使用任何旧的计算机作为服务器都可以。但 对用于生产的服务器来说，应该坚持遵循这些硬件建议。
一般来说，关键的生产DBMS应该运行在自己的专用服务器上。
MySQL是用一系列的默认设置预先配置的，从这些设置开始通常 是很好的。但过一段时间后你可能需要调整内存分配、缓冲区大 小等。（为查看当前设置，可使用SHOW VARIABLES;和SHOW STATUS;。）
MySQL一个多用户多线程的DBMS，换言之，它经常同时执行多 个任务。如果这些任务中的某一个执行缓慢，则所有请求都会执 行缓慢。如果你遇到显著的性能不良，可使用SHOW PROCESSLIST 显示所有活动进程（以及它们的线程ID和执行时间）。你还可以用KILL命令终结某个特定的进程（使用这个命令需要作为管理员登 录） 。
总是有不止一种方法编写同一条SELECT语句。应该试验联结、并、 子查询等，找出最佳的方法。
使用EXPLAIN语句让MySQL解释它将如何执行一条SELECT语句。
一般来说，存储过程执行得比一条一条地执行其中的各条MySQL 语句快。
应该总是使用正确的数据类型。
决不要检索比需求还要多的数据。换言之，不要用SELECT *（除 非你真正需要每个列）。
有的操作（包括INSERT）支持一个可选的DELAYED关键字，如果 使用它，将把控制立即返回给调用程序，并且一旦有可能就实际 执行该操作
在导入数据时，应该关闭自动提交。你可能还想删除索引（包括 FULLTEXT索引），然后在导入完成后再重建它们。
必须索引数据库表以改善数据检索的性能。确定索引什么不是一 件微不足道的任务，需要分析使用的SELECT语句以找出重复的 WHERE和ORDER BY子句。如果一个简单的WHERE子句返回结果所花 的时间太长，则可以断定其中使用的列（或几个列）就是需要索 引的对象。
你的SELECT语句中有一系列复杂的OR条件吗？通过使用多条 SELECT语句和连接它们的UNION语句，你能看到极大的性能改 进。
索引改善数据检索的性能，但损害数据插入、删除和更新的性能。 如果你有一些表，它们收集数据且不经常被搜索，则在有必要之 前不要索引它们。（索引可根据需要添加和删除。）
LIKE很慢。一般来说，最好是使用FULLTEXT而不是LIKE。
数据库是不断变化的实体。一组优化良好的表一会儿后可能就面 目全非了。由于表的使用和内容的更改，理想的优化和配置也会 改变。
最重要的规则就是，每条规则在某些条件下都会被打破