Mysql の on、in、as、where の違いは何ですか?

Mysql の on、in、as、where の違い

答え: Where クエリ条件は、内部および外部に接続するときに on をエイリアスとして使用し、特定の値がクエリに含まれるかどうかをクエリします。特定の条件

2つのテーブルを作成します:student、score

student:

score:

where

SELECT * FROM student WHERE s_sex='男'

##例: on

SELECT * FROM student LEFT JOIN score on student.s_id=score.s_id;

on と where の組み合わせ:

SELECT * FROM student LEFT JOIN score on student.s_id=score.s_id WHERE s_name='赵雷'

##例: in

SELECT * FROM score WHERE s_id in (SELECT s_id FROM student WHERE s_name='赵雷')

#as

select * from score as a LEFT JOIN student as b on a.s_id=b.s_id where s_name='赵雷'

#MySQL ステートメントの問題解決

1. 左結合データのフィルタリングの問題

以降の条件では、左結合の右側のテーブルのみをフィルタリングできます。左のテーブルが右のテーブルのデータと一致しない場合、元のテーブルには null が表示されます。右テーブルの位置。左結合の左側のテーブル データは制約されていないため、表示されます。where に後者の条件が追加された後、すべてのデータがフィルタリングされます。

2. 同じデータが繰り返しフィルタリングされて使用されます。

with <name> as()

as を使用して、mysql で一時テーブルを生成できます。 は一時テーブルの名前です。以下:

with arc as( 
    select id,arc.title,update_time,is_top,cId,pid,name_id from article arc where is_del = 0 
) 
select * from arc

with...as のスコープは 1 回の SQL 実行の間のみ持続し、実行後は存在しなくなります。例によれば、article テーブルを処理することになっていますが、そうではありません。テーブル内のすべてのデータが必要なので、最初にフィルタリングして作成し、一時テーブル アークを操作します。

上記の例の単純な操作であれば、 with...as を使用する必要はありませんが、article テーブルを他のテーブルと結合したりネストしたりする必要がある場合は、 with...as を使用する必要があります。 is_del = を複数回実行する 0 判定の場合、最終的な SQL ステートメントは非常に複雑でエラーが発生しやすい可能性がありますが、arc を使用するとデータのフィルタリングを繰り返す必要がありません。

with...as 内の SQL はさらに複雑になる可能性があります。たとえば、article テーブルには name_id がありますが、多くの場合、name を使用する必要があります。with...as で検索できます。一時テーブルを使用して他の操作を実行します。

3. 特定のフィールドに従って並べ替え、各カテゴリの最後の 3 つのデータまたは最初の 3 つのデータを取得します。

これは比較的古典的な問題です。私は初心者で 1 つしか知りません。問題を解決する方法ですが、シンプルで人気のあるものになるように最善を尽くします。

例:

select * from ( 
select cId,title,content( 
    select count(*)+1 from arc a1 where (a1.cId = a2.cId) and a1.updateTime > a2.updateTime 
)updateTimeSort from arc a2 
) a3 
where updateTimeSort <= 3 order by cId,updateTime desc

この例では、cId はカテゴリ ID、updateTime は更新時刻です。問題の解決策は、アーク内のカテゴリごとに 3 つの最新の更新データを選択することです。 , ニュースのホームページと同じです。カテゴリごとに最新の 3 つのニュース項目を選択します。データベース内のデータによると、order by cId、updateTime desc を使用してデータをカテゴリと更新時間で並べ替えることができますが、取得するには各カテゴリの特定のデータについては、既存のデータベースではそれができないため、一時フィールドを追加できます。

updateTimeSort このカテゴリ内の各カテゴリの各サブ項目の並べ替えを表します。現在の問題では、この一時フィールドはフィールド updateTime に関連付けられている必要があります。更新時間に従って、各サブ項目はカテゴリは「並べ替え」です。

サンプル コードに示すように、2 つのテーブル a1 と a2 が見つかります。これらは両方とも円弧テーブルのエイリアスです。これらはサブクエリの形式で結合されています。a2 をメインとして、次のように進みます。 a1 テーブルにカテゴリを検索し、a2 の現在のデータは同じですが、更新時刻が a2 の現在のデータよりも遅いと、count(*) 1 が表示されます。これは、数値が 1 増加することを意味します。データが属するカテゴリの時点でデータが更新された場合に限り、値を 1 つ増やすことはできません。遅くとも count(*) の値は 0 です。count(*) 1 を使用すると、次のことができます。データを1からソートします。

最終的に、updateTimeSort <= 3 のデータを選択するだけで済みます。最も古い公開ニュースをフィルタリングしたい場合は、updateTimeSort のフィルタリング ロジックを変更するだけで済みます。これは ## になります。 ## サンプルコードの ##a1.updateTime > a2.updateTime が a1.updateTime < a2.updateTime

サンプルコードには別のテーブル a3 があることがわかります。一時テーブル。以前に学習したように、一時テーブルを生成できます。このコードからわかるように、一時テーブルは別の形式で存在することもできます。with...は、SQL が複雑な場合にのみ使用します。一般に、この種のメソッドは多くの問題を解決するのに役立ちますが、それぞれに長所と短所があるため、状況に応じて使用してください。

4、业务逻辑书写位置问题

接触sql多了会发现，sql其实能帮我们解决一定的业务问题，明显的有sql的存储过程和方法，对sql语句的批量处理其实在一定程度上帮我们解决一定的业务问题，但缺点也很明显，当新手接触这个项目时他很难搞清楚某个功能到底是如何实现的，不利于维护。

一般来说我们解决业务是在server层，有时会使用sql解决一些问题，但很少，在sever处理受制于计算机硬件，在数据库处理受制于数据库性能，相比之下，计算机硬件更易于扩展，因此还是不推荐大量使用sql解决问题的。

例如上个问题：根据某个字段排序取每个类别最后三条数据或前三条数据问题，虽然问题基本解决但让存在一些 ‘bug’，例如排序时会产生1、2、3、3、4这种排序，这是因为同个类别内有两条数据更新时间重复了，那我们直观想法(还是要看个人经验值)应该是，既然问题出在数据库，那应该在数据库查询的时候就解决这个问题，但事实上，让数据库去解决并不好解决，数据库的强项在于各种搜索算法，不在于逻辑处理，因此我们就要转移到server层处理，会有不少人陷于这个坑，花费大量时间去找办法让数据库去处理这类问题，但其实就算数据库处理得了，它也不一定有server层处理的效率高，当然如果是为了学习更多东西，这些时间也是值得花的，但是这种解题思路还是要改变下的。将1、2、3、3、4问题交给server处理也就是利用java等高级语言处理这种问题，相信熟用这些语言的开发者解决这些问题都是小case了。

5、查找另一表内和本表相关字段的数量

先复习下知识：用过count函数的人都清楚一旦使用count这类聚合函数，不做其他处理数据就会归为一行数据，但很多时候我们并不期望这样的结果，以此就要想些办法能用聚合函数，也能获取很多数据，我常用的是利用group by分组。

回归问题，现有(现不讨论表是否合理)文章表(id,title,content)有文章id，标题，文章内容三个字段，点赞收藏表(id,arc_id,fav,like)有表id，文章id，收藏字段(0未收藏，1收藏)，点赞字段(0未点赞，1点赞)，现要查询文章表内每篇文章的点赞收藏数，sql语句：

select art.title,art.content, 
count(case afl.fav when 1 then 1 end) as collectNum, 
count(case afl.like when 1 then 1 end) as likeNum 
from article art 
left join article_favor_like afl on afl.arc_id = art.id 
group by afl.arc_id //这是关键

如果没有group by afl.arc_id 后果就是，查出来一行数据，数据还牛头不对马嘴，但通过对文章收藏表中的文章id进行分组就可以针对每个文章id查询数据，这样left join时右表就有每个文章id对相应的收藏数与点赞数，而不是表内所有点赞数和收藏数，最终数据也是我们所需的。

6、关于union的使用

例子：

select id,title,content,1 isArc from arc 
union 
select id,name,content,0 isArc from news

• 使用union进行的是上下整合

• 被联合的数据列数要求一致

• 列数相同，数据类型不同会自动进行数据类型转换

• 联合后的列的名字由联合中第一次出现的列名为依据，即使后续被联合数据有自己的列名也不会使用，在例子中最终列名为：id,title,content,name等列名不会使用，因此使用union一般配合别名使用统一结果。

• 有时候会区分数据是哪个表的，可以通过附加额外的字段来区别，就像例子中的isArc字段，news表中的isArc可以不写，原因也就是第4条，最终列名由第一次出现的列名决定，后续数据列名有没有都可以。

7、limit的巧用

limit一般用于分页，功能是获取指定区间内的数据，因此我们也可以用它来减少数据库的查询，例子：

select * from arc where id = 12 limit 1

数据库查询由索引还好，没有索引是要遍历数据库的，有些数据经由条件筛选在逻辑上应该是唯一的，使用limit 1可以使数据库查询到该数据时不再搜索，减少数据库搜索次数，但这种方法仅是一种技巧，想大幅度优化sql还要另想办法。

8、update ignore和insert ignore的使用

//标题是唯一索引，'新标题'存在则更新操作不执行 
update ignore arc set title = '新标题' 
 
//标题是唯一索引，'标题1号'存在则插入操作不执行 
insert ignore into arc values(null,'标题1号','文章内容')

有这种需求，数据存在时不执行任何操作，不存在则更新或插入，一个办法是使用ingore，它会忽略数据库报错，而数据库执行原子操作时报错是会回滚的，因此只要我们给数据加上主键或唯一索引，当被更新字段或插入字段与原有数据冲突时会报错，但因为ingore会忽视这种报错，后端也就不会报错，sql也未执行，达到了目的，有人会对报错敏感，其实也没什么，报错也是在检查数据是发现不合理之处给的一个提醒或警告，对数据库无害的。

9、mysql存在更新，不存在则插入

区别于上面那个需求，这个是当插入的数据存在时更新数据，不再是不做任何操作，例子：

//本例子中title不是唯一索引，id是主键 
insert into arc values(1,'标题1号','文章内容') 
on duplicate key update title='标题1号'
//若要更新多个字段使用','隔开，例：title='标题1号',content='文章内容'

在例子中，当id为1的数据存在时，更新标题和内容，不存在则插入，如果执行更新操作，未设置新值的字段保持原来的值。

还有一个REPLACE INTO也可以达到这种效果，区别在于，REPLACE INTO更新时是先删除后插入会破坏原有索引，id为3的数据更新时会删除插入id为4的数据，未更新新值的字段设置为默认值或null。

无论是两个中的哪种方式判断数据是否存在的依据都是主键和唯一索引。

以上がMysql の on、in、as、where の違いは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。