mysql按照每天每月等统计数据（连续不间断，当天月没有数据为0）

   在统计数据的需求中很容易出现按照天来统计数据的场景，有时某一列的维度在那天并没有产生数据，但是又没有一列是可以确保每天都是有数据的，由于mysql中并没有fulljoin这样的关联方式，在这种情况下关联查询就有些费劲，解决的办法也是多种多样，毕竟条条大路通罗马嘛，其他的就不说了，这里介绍一种相对方便的方法。

   产生一个足够长的时间列，这个列要能够包含想要统计的所有日期。这个思路的实现很泛，可以创建一个日期的临时表，然后将想要查的日期插入，抛开创建表比较麻烦之外，一般在职能比较完善的公司，生产环境创建表或者修改数据是需要交给专门的DBA去 *** 作的，各种流程。。。相对这个较简单的一种方式就是创建存储过程，然后产生时间列，这也是一种解决办法。

   我的思路是先定义一个时间变量并初始化，然后和某个数据足够多的表关联查询获取时间列，这个表一般选取某张要查的表即可，数据条数只要超过需要查询的条数即可，足够即可，太多就是浪费，降低查询效率。

   比如说我要查询2018-01-10到2018-01-20每天的数据，那么就可以写成

   其中，cdate是我定义的一个时间变量，初始化的值是2018-01-09，因为在外面那部分执行之后值已经加1了，已经不是2018-01-10了；data_t是我关联产生记录的实体表，这个表只有一个要求，就是能帮我们产生足够的时间列条数，后面的limit 15是帮助我产生15条时间记录，可以换成其他条件；生成的t0其实就是15条全为2018-01-09的记录，外面的查询在每扫描一条t0的记录就会加1天，这样就会产生连续的时间列；WHERE后面是最终查询的截止条件，换成其他的也可以。

关联其他表举例：

查询从2018-01-10到当前日期每天的统计数据

  通过上面的例子我想大部分人应该可以灵活变化了，比如查询多少天内每天的统计数据，某几个月内每月的统计数据等等，通过修改上面给的例子里面的sql完全可以做到，可以说这种思路就是个‘万能模板’，希望本文能够帮到大家。

一、普通索引

这是最基本的索引，它没有任何限制。有以下几种创建方式：

1.创建索引

代码如下:

CREATE INDEX indexName ON mytable(username(length))

如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。

2.修改表结构

代码如下:

ALTER mytable ADD INDEX [indexName] ON (username(length)) -- 创建表的时候直接指定。

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) )

-- 删除索引的语法：

DROP INDEX [indexName] ON mytable

二、唯一索引

它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：

代码如下:

CREATE UNIQUE INDEX indexName ON mytable(username(length))

-- 修改表结构

ALTER mytable ADD UNIQUE [indexName] ON (username(length))

-- 创建表的时候直接指定

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) )

三、主键索引

它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

代码如下:

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) )

当然也可以用 ALTER 命令。记住：一个表只能有一个主键。

四、组合索引

为了形象地对比单列索引和组合索引，为表添加多个字段：

代码如下:

CREATE TABLE mytable( ID INT NOT NULL,username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL )

为了进一步榨取MySQL的效率，就要考虑建立组合索引。

二：使用索引的注意事项

使用索引时，有以下一些技巧和注意事项：

1.索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

2.使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O *** 作。

3.索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序 *** 作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

4.like语句 *** 作

一般情况下不鼓励使用like *** 作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

5.不要在列上进行运算

select * from users where YEAR(adddate)<2007

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成:

select * from users where adddate<‘2007-01-01'

6.不使用NOT IN和<> *** 作。

三：sql优化原则

常见的简化规则如下：

1.不要有超过5个以上的表连接（JOIN）

2.考虑使用临时表或表变量存放中间结果。

3.少用子查询

4.视图嵌套不要过深,一般视图嵌套不要超过2个为宜。

5.连接的表越多，其编译的时间和连接的开销也越大，性能越不好控制。

6.最好是把连接拆开成较小的几个部分逐个顺序执行。

7.优先执行那些能够大量减少结果的连接。

8.拆分的好处不仅仅是减少SQL Server优化的时间，更使得SQL语句能够以你可以预测的方式和顺序执行。

如果一定需要连接很多表才能得到数据，那么很可能意味着设计上的缺陷。

库建立好之后基本不动,和我们接触最频繁的是表. 建表就是声明字段的过程!

选择合适的类型[速度快 减少硬盘占用]

存储空间，还是存储范围有区别？

答案： 两者本质完全一样 ，只是在一些特殊情况下两者显示有区别(只是在显示的时候补全0的位数不一样)

实验

*zerofill 零填充(本字段同时即自动带有unsigned属性,因为负数不能零填充)

如 数字2在固定宽度4时 零填充 即为0002

M值是一个整数(固定宽度值)，只有在字段有零填充zerofill属性时 规定M值才有意义！

M值只是 显示效果 ,不会影响实际数据值！

如M值为1,实际值255,一样会显示255

列可以声明默认值(推荐声明)

因为null无法和别的值比较

null = 0 返回null

null <>0 返回null

null只能用is或is not比较 null is null当然对的。

例子：

【浮点型】有误差，不稳定！定点数更精确。

实际测试数据

Float(M,D)

M精度(总位数,不包含点) 精度值M 影响 存储的 值的范围.

D标度(小数位) 小数点后有几位（mysql比较特殊，mssql/oracle都不能指定）

testcolumn float(5,2) unsigned 范围0到999.99

float(5,2)的范围-999.99到999.99

给float(5,2)这样的字段插入值在进位时有一些规矩:暂时没搞清楚，不是简单的四舍五入

插入值688.826实际是688.83 末尾6 进位

插入值688.825实际是688.83 末尾5 进位

插入值688.824实际是688.82 末尾4 舍去

插入值688.005实际是688.00

插入值688.015实际是688.01 末尾5 5前面是1 舍去

插入值688.025实际是688.02 末尾5 5前面是2 舍去

插入值688.035实际是688.03 末尾5 5前面是3 舍去

插入值688.045实际是688.04 末尾5 5前面是4 舍去

一般使用tinyint、char(1)、enum类型。

varchar(M)

M代表宽度 即可容纳的【字符数】 (并不是字节数) varchar占用的字节数与编码有关:

utf-8 一个汉字3字节　英文字母1字节

对于utf8mb4号称占用4字节但是并不绝对(在utf8可以覆盖到的范围则仍然占用3字节)

utf8mb4最有优势的应用场景:存储emoji表情

例子：

性能太差，不推荐

MySQL在5.6.4版本之后，TimeStamp和DateTime支持到微妙

一个例子：

以如下这张表为例

show privileges 命令可以查看全部权限

查询时从user->db->table_pirv->columns_pirv依次验证，如果通过则执行查询。

本课程涉及建表SQL

场景1：歌单按时间排序

场景2：统计云音乐创建歌单的用户

场景3-1：统计云音乐创建歌单的用户列表和每人创建歌单的数量。

场景3-2：统计云音乐创建歌单的用户列表和每人创建歌单的数量，并且只显示歌单数量排序大于等于2的用户

SQL进阶语法-like

场景4：查询一个月内创建歌单（从第6行开始显示10条记录）

场景5：对于未录入歌曲的歌单(trackcount = null)，输出结果时歌曲数返回0.

连接的作用是用一个SQL语句把多个表中相互关联的数据查出来

场景6：查询收藏“老男孩”歌单的用户列表

子查询：内层查询的结果作为外层的比较条件。一般子查询都可以转换成连接，推荐使用连接。

场景7：查询出没有用户收藏的歌单

场景8：老板想看创建和收藏歌单的所有用户，查询play_list和play_fav两表中所有的userid

实例还是上节中的那些表

场景1：查询每张专辑总的点播次数和每首歌的平均点播次数。

场景2：查询全部歌曲中的最大的播放次数和最小的播放次数。

场景2续：查询播放次数最多的歌曲

count(*) 和 count(1) 基本一样，没有明显的性能差异。

count(*) 和 count(song_name) 差别在于 count(song_name) 会除去song_name is null的情况

场景3：显示每张专辑的歌曲列表

实例：查询一个月内userid为1,3,5的用户创建的歌单

学生表：

用于更正成绩的触发器：

---