MySQL中的常用关键字

很久不用MySQL,感觉又是一个新的玩意儿了,写起SQL语句来感觉好陌生,确实是很久了!

distinct

查询出某个字段不重复的记录。可用distinct来返回不重复字段的条数count(distinct id)

limit

记得这个可以用来做分页。它后面可以接受一个或两个数字参数。参数必须是一个整数常量。如果给定两个参数,第一个参数指定第一个返回记录行的偏移量,第二个参数指定返回记录行的最大数目

//初始记录行的偏移量是 0(而不是 1):
mysql> SELECT * FROM table LIMIT 5,10; //检索记录行6-15

//为了检索从某一个偏移量到记录集的结束所有的记录行,可以指定第二个参数为 -1:
mysql> SELECT * FROM table LIMIT 95,-1; // 检索记录行 96-last

//如果只给定一个参数,它表示返回最大的记录行数目。换句话说,LIMIT n 等价于 LIMIT 0,n:
mysql> SELECT * FROM table LIMIT 5;     //检索前 5 个记录行

limit的效率高?

常说的Limit的执行效率高,是对于一种特定条件下来说的:即数据库的数量很大,但是只需要查询一部分数据的情况。高效率的原理是:避免全表扫描,提高查询效率。比如:每个用户的email是唯一的,如果用户使用email作为用户名登陆的话,就需要查询出email对应的一条记录。 SELECT * FROM t_user WHERE email=?;上面的语句实现了查询email对应的一条用户信息,但是由于email这一列没有加索引,会导致全表扫描,效率会很低。 SELECT * FROM t_user WHERE email=? LIMIT 1;加上LIMIT 1,只要找到了对应的一条记录,就不会继续向下扫描了,效率会大大提高。

limit的效率低?

在一种情况下,使用limit效率低,那就是:只使用limit来查询语句,并且偏移量特别大的情况。做以下实验: 语句1:select * from table limit 150000,1000;语句2:select * from table while id>=150000 limit 1000;语句1为0.2077秒;语句2为0.0063秒。两条语句的时间比是:语句1/语句2=32.968

比较以上的数据时,我们可以发现采用where...limit....性能基本稳定,受偏移量和行数的影响不大,而单纯采用limit的话,受偏移量的影响很大,当偏移量大到一定后性能开始大幅下降。不过在数据量不大的情况下,两者的区别不大。所以应当先使用where等查询语句,配合limit使用,效率才高。在sql语句中,limt关键字是最后才用到的。以下条件的出现顺序一般是:where->group by->having-order by->limit

OFFSET

为了与 PostgreSQL 兼容,MySQL 也支持句法: LIMIT # OFFSET #。经常用到在数据库中查询中间几条数据的需求比如下面的sql语句:

selete * from testtable limit 2,1;selete * from testtable limit 2 offset 1;

注意: 1.数据库数据计算是从0开始的 2.offset X是跳过X个数据,limit Y是选取Y个数据 3.limit  X,Y  中X表示跳过X个数据,读取Y个数据

这两个都是能完成需要,但是他们之间是有区别的: ①是从数据库中第三条开始查询,取一条数据,即第三条数据读取,一二条跳过 ②是从数据库中的第二条数据开始查询两条数据,即第二条和第三条。

UNION & UNION ALL

union all是直接连接,取到得是所有值,记录可能有重复   union 是取唯一值,记录没有重复。

1、UNION 的语法如下: [SQL 语句 1] UNION [SQL 语句 2]

2、UNION ALL 的语法如下: [SQL 语句 1] UNION ALL [SQL 语句 2]

效率

UNION和UNION ALL关键字都是将两个结果集合并为一个,但这两者从使用和效率上来说都有所不同。

1、对重复结果的处理:UNION在进行表链接后会筛选掉重复的记录,Union All不会去除重复记录。

2、对排序的处理:Union将会按照字段的顺序进行排序;UNION ALL只是简单的将两个结果合并后就返回。

从效率上说,UNION ALL 要比UNION快很多,所以,如果可以确认合并的两个结果集中不包含重复数据且不需要排序时的话,那么就使用UNION ALL。

简单应用

将一个表的内容弄成两份到一个输出中:

select * from
(select * from players) b
UNION all
(select * from players) ;

join相关

left join(左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录 right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录 inner join(等值连接) 只返回两个表中联结字段相等的行

参考: https://www.cnblogs.com/acm-bingzi/p/msqlLimit.html

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd