ソフトウェア開発に携わるほとんどの人は、データベースの扱いと切り離せない関係にあります。特に ERP 開発者は、データ量が多く、人材の入れ替わりが多い場合、ストアド プロシージャに数千行が含まれることがよくあります。では、システムが次の期間もスムーズに実行できることを確認できますか?次の人がストアド プロシージャを理解できるようにすることはできますか?次に、会社の通常の研修と個人の仕事の経験に基づいてそれを共有します。これが皆さんの役に立つことを願っています。
SQL ステートメントを知るには、sqlserver クエリ アナライザーが SQL ステートメントをどのように実行するかを知る必要があると思います。私たちの多くは、実行プランを調べたり、クエリ ステートメントやストアド プロシージャが実行される理由を監視および調整したりするためにプロファイルを使用します。しかし、クエリ アナライザーの実行ロジック シーケンスがわかっていて、自信を持って開始できる場合、自信を持って開始できるでしょうか?
以下は、私が個人的に考える SQL プログラミングの良い習慣です:
クエリの論理的な実行順序
実行順序
必要なデータ
繰り返しの作業をできるだけ少なくする
一時テーブルとテーブル変数の使用に注意する
-
サブクエリの使用
-
使用する可能な限りインデックスを作成します
複数のテーブルの結合とインデックス
その他
1: 論理実行クエリの順序
(1) FROM < left_table> (3) < join_type> JOIN < right_table> (2) ON < join_condition> (4) WHERE < where_condition> (5) GROUP BY < group_by_list> (6) WITH {cube | rollup} (7) HAVING < having_condition> (8) SELECT (9) DISTINCT (11) < top_specification> < select_list> (10) ORDER BY < order_by_list>
標準SQL 解析順序:
(1).FROM 子句 组装来自不同数据源的数据 (2).WHERE 子句 基于指定的条件对记录进行筛选 (3).GROUP BY 子句 将数据划分为多个分组 (4).使用聚合函数进行计算 (5).使用HAVING子句筛选分组 (6).计算所有的表达式 (7).使用ORDER BY对结果集进行排序
2 番目の実行順序:
1.FROM: FROM 句の最初の 2 つのテーブルでデカルト積を実行し、仮想テーブル vt1 を生成します
2.ON: Apply ON を満たす場合にのみ vt1 テーブルにフィルターします
3.OUTER(join): OUTER JOIN が指定されている場合、保存されたテーブルに見つからない行は vt2 に追加されますt3 を外部行として生成します。 3 つ以上のテーブルが含まれている場合は、前の接続によって生成された結果テーブルと次のテーブルに対して手順と手順を繰り返し、直接終了します
4.WHERE: vt3 の WHERE フィルター が true の行のみが含まれている必要があります vt4
5.GROUP BY: GROUP BY 句の列リストに従って vt4 の行をグループ化して vt5
6.CUBE| ROLLUP: スーパーグループを vt6 に挿入して vt6 を生成します
7.HAVING: HAVING フィルターを vt6 に適用します。
8.SELECT: 選択を処理しますvt8 を生成するリスト
9.DISTINCT: 繰り返されます vt8 から行が削除されて vt9 が生成されます
10.ORDER BY: order by 句の列リストで vt9 の行をソートして、カーソル vc10
11.TOP: vc10 の先頭から指定されたものを選択します 行の数または割合は vt11 を生成し、呼び出し元に戻ります
ここを見て、linqtosql で使用される構文は少し似ていますか? sqlserver の実行順序を理解すると、パフォーマンスを考慮して関数を実装するという日常の SQL 習慣がさらに身に付きます。データベースは集合演算を実行できるツールであり、このツールを最大限に活用する必要があります。 . 、いわゆるセット操作は実際にはバッチ操作であり、クライアントでの大量のデータのループ操作を最小限に抑え、代わりに SQL ステートメントまたはストアド プロシージャを使用することを意味します。
3. 必要なデータのみを返す
データをクライアントに返すには、少なくともデータベースの抽出、ネットワーク送信、クライアントによるデータの受信、およびデータのクライアント処理が必要になります。サーバー、ネットワーク、クライアント上での非効率な作業による害は明らかです。このような事態を避けるためには、次の点に注意する必要があります。必要なフィールドを選択します。
(2) SQL ステートメント内で複数のテーブルを接続する場合は、テーブルのエイリアスを使用し、各カラムにそのエイリアスを接頭辞として付けてください。これにより、解析時間を短縮し、カラムの曖昧さによって引き起こされる構文を減らすことができます。 テーブル table1 (ID、col1) と table2 (ID、col2) がある場合
Select A.ID, A.col1, B.col2 -- Select A.ID, col1, col2 –不要这么写,不利于将来程序扩展 from table1 A inner join table2 B on A.ID=B.ID Where …B. 垂直的な観点から:
(1) WHERE 句を合理的に記述し、WHERE のない SQL ステートメントを記述しない。
(2) SELECT TOP N * -- WHERE 条件がない場合は代わりにこれを使用します
4: 反復作業をできるだけ少なくしますA. 同じステートメントの複数の実行、特にいくつかのステートメントの複数の実行を制御します。基本データ 実行は、多くのプログラマーがほとんど注意を払わないものです。
B. 複数のデータ変換を減らす。データ変換の必要性は設計上の問題である可能性がありますが、回数を減らすことはプログラマーが行うことができます。 C. 不必要なサブクエリと結合テーブルを削除する。サブクエリは通常、実行プランの外部結合として解釈され、追加のオーバーヘッドが発生します。
D、合并对同一表同一条件的多次UPDATE,比如
UPDATE EMPLOYEE SET FNAME='HAIWER' WHERE EMP_ID=' VPA30890F' UPDATE EMPLOYEE SET LNAME='YANG' WHERE EMP_ID=' VPA30890F'
这两个语句应该合并成以下一个语句
UPDATE EMPLOYEE SET FNAME='HAIWER',LNAME='YANG' WHERE EMP_ID=' VPA30890F'
E、UPDATE操作不要拆成DELETE操作+INSERT操作的形式,虽然功能相同,但是性能差别是很大的。
五、注意临时表和表变量的用法
在复杂系统中,临时表和表变量很难避免,关于临时表和表变量的用法,需要注意:
A、如果语句很复杂,连接太多,可以考虑用临时表和表变量分步完成。
B、如果需要多次用到一个大表的同一部分数据,考虑用临时表和表变量暂存这部分数据。
C、如果需要综合多个表的数据,形成一个结果,可以考虑用临时表和表变量分步汇总这多个表的数据。
D、其他情况下,应该控制临时表和表变量的使用。
E、关于临时表和表变量的选择,很多说法是表变量在内存,速度快,应该首选表变量,但是在实际使用中发现,
(1)主要考虑需要放在临时表的数据量,在数据量较多的情况下,临时表的速度反而更快。
(2)执行时间段与预计执行时间(多长)
F、关于临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择,一般情况下,
SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多,
但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS,在多用户并发环境下,容易阻塞其他进程,
所以我的建议是,在并发系统中,尽量使用CREATE TABLE + INSERT INTO,而大数据量的单个语句使用中,使用SELECT INTO。
六、子查询的用法(1)
子查询是一个 SELECT 查询,它嵌套在 SELECT、INSERT、UPDATE、DELETE 语句或其它子查询中。
任何允许使用表达式的地方都可以使用子查询,子查询可以使我们的编程灵活多样,可以用来实现一些特殊的功能。但是在性能上,
往往一个不合适的子查询用法会形成一个性能瓶颈。如果子查询的条件中使用了其外层的表的字段,这种子查询就叫作相关子查询。
相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入。 关于相关子查询,应该注意:
(1)
A、NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法。比如: SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID NOT IN (SELECT PUB_ID FROM TITLES WHERE TYPE = 'BUSINESS') 可以改写成: SELECT A.PUB_NAME FROM PUBLISHERS A LEFT JOIN TITLES B ON B.TYPE = 'BUSINESS' AND A.PUB_ID=B. PUB_ID WHERE B.PUB_ID IS NULL
(2)
SELECT TITLE FROM TITLES WHERE NOT EXISTS (SELECT TITLE_ID FROM SALES WHERE TITLE_ID = TITLES.TITLE_ID)
可以改写成:
SELECT TITLE FROM TITLES LEFT JOIN SALES ON SALES.TITLE_ID = TITLES.TITLE_ID WHERE SALES.TITLE_ID IS NULL
B、 如果保证子查询没有重复 ,IN、EXISTS的相关子查询可以用INNER JOIN 代替。比如:
SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID IN (SELECT PUB_ID FROM TITLES WHERE TYPE = 'BUSINESS')
可以改写成:
SELECT A.PUB_NAME --SELECT DISTINCT A.PUB_NAME FROM PUBLISHERS A INNER JOIN TITLES B ON B.TYPE = 'BUSINESS' AND A.PUB_ID=B. PUB_ID
(3)
C、 IN的相关子查询用EXISTS代替,比如
SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID IN (SELECT PUB_ID FROM TITLES WHERE TYPE = 'BUSINESS')
可以用下面语句代替:
SELECT PUB_NAME FROM PUBLISHERS WHERE EXISTS (SELECT 1 FROM TITLES WHERE TYPE = 'BUSINESS' AND PUB_ID= PUBLISHERS.PUB_ID)
D、不要用COUNT(*)的子查询判断是否存在记录,最好用LEFT JOIN或者EXISTS,比如有人写这样的语句:
SELECT JOB_DESC FROM JOBS WHERE (SELECT COUNT(*) FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)=0
应该改成:
SELECT JOBS.JOB_DESC FROM JOBS LEFT JOIN EMPLOYEE ON EMPLOYEE.JOB_ID=JOBS.JOB_ID WHERE EMPLOYEE.EMP_ID IS NULL SELECT JOB_DESC FROM JOBS WHERE (SELECT COUNT(*) FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)<>0
应该改成:
SELECT JOB_DESC FROM JOBS WHERE EXISTS (SELECT 1 FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)
七:尽量使用索引
建立索引后,并不是每个查询都会使用索引,在使用索引的情况下,索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引,
索引的选择和使用方法是SQLSERVER的优化器自动作的选择,而它选择的根据是查询语句的条件以及相关表的统计信息,这就要求我们在写SQL
语句的时候尽量使得优化器可以使用索引。为了使得优化器能高效使用索引,写语句的时候应该注意:
(1)
A、不要对索引字段进行运算,而要想办法做变换,比如
SELECT ID FROM T WHERE NUM/2=100
应改为:
SELECT ID FROM T WHERE NUM=100*2 SELECT ID FROM T WHERE NUM/2=NUM1
如果NUM有索引应改为:
SELECT ID FROM T WHERE NUM=NUM1*2
如果NUM1有索引则不应该改。
(2)
发现过这样的语句:
SELECT 年,月,金额 FROM 结余表 WHERE 100*年+月=2010*100+10
应该改为:
SELECT 年,月,金额 FROM 结余表 WHERE 年=2010 AND月=10
B、 不要对索引字段进行格式转换
日期字段的例子:
WHERE CONVERT(VARCHAR(10), 日期字段,120)='2010-07-15'
应该改为
WHERE日期字段〉='2010-07-15' AND 日期字段<'2010-07-16'
ISNULL转换的例子:
WHERE ISNULL(字段,'')<>''应改为:WHERE字段<>'' WHERE ISNULL(字段,'')=''不应修改 WHERE ISNULL(字段,'F') ='T'应改为: WHERE字段='T' WHERE ISNULL(字段,'F')<>'T'不应修改
(3)
C、 不要对索引字段使用函数
WHERE LEFT(NAME, 3)='ABC' 或者WHERE SUBSTRING(NAME,1, 3)='ABC'
应改为: WHERE NAME LIKE 'ABC%'
日期查询的例子:
WHERE DATEDIFF(DAY, 日期,'2010-06-30')=0
应改为:
WHERE 日期>='2010-06-30' AND 日期 <'2010-07-01'
WHERE DATEDIFF(DAY, 日期,'2010-06-30')>0
应改为:
WHERE 日期 <'2010-06-30'
WHERE DATEDIFF(DAY, 日期,'2010-06-30')>=0
应改为:
WHERE 日期 <'2010-07-01'
WHERE DATEDIFF(DAY, 日期,'2010-06-30')<0
应改为:
WHERE 日期>='2010-07-01'
WHERE DATEDIFF(DAY, 日期,'2010-06-30')<=0
应改为:
WHERE 日期>='2010-06-30'
D、不要对索引字段进行多字段连接
比如:
WHERE FAME+ '. '+LNAME='HAIWEI.YANG'
应改为:
WHERE FNAME='HAIWEI' AND LNAME='YANG'
八. 多表连接条件与索引选择
A、多表连接的时候,连接条件必须写全,宁可重复,不要缺漏。
B、连接条件尽量使用聚集索引
C、注意ON、WHERE和HAVING部分条件的区别
ON是最先执行, WHERE次之,HAVING最后,因为ON是先把不符合条件的记录过滤后才进行统计,它就可以减少中间运算要处理的数据,按理说应该速度是最快的,WHERE也应该比 HAVING快点的,因为它过滤数据后才进行SUM,在两个表联接时才用ON的,所以在一个表的时候,就剩下WHERE跟HAVING比较了
考虑联接优先顺序:
(1)INNER JOIN (2)LEFT JOIN (注:RIGHT JOIN 用 LEFT JOIN 替代) (3)CROSS JOIN
九. 其它
A、在IN后面值的列表中,将出现最频繁的值放在最前面,出现得最少的放在最后面,减少判断的次数
B、注意UNION和UNION ALL的区别。--允许重复数据用UNION ALL好
C、注意使用DISTINCT,在没有必要时不要用
D、TRUNCATE TABLE 与 DELETE 区别
E、减少访问数据库的次数
还有就是我们写存储过程,如果比较长的话,最后用标记符标开,因为这样可读性很好,即使语句写的不怎么样但是语句工整,C# 有region
sql我比较喜欢用的就是
--startof 查询在职人数
sql语句
--end of
正式机器上我们一般不能随便调试程序,但是很多时候程序在我们本机上没问题,但是进正式系统就有问题,但是我们又不能随便在正式机器上操作,那么怎么办呢?我们可以用回滚来调试我们的存储过程或者是sql语句,从而排错。
BEGIN TRAN UPDATE a SET 字段='' ROLLBACK
作业存储过程我一般会加上下面这段,这样检查错误可以放在存储过程,如果执行错误回滚操作,但是如果程序里面已经有了事务回滚,那么存储过程就不要写事务了,这样会导致事务回滚嵌套降低执行效率,但是我们很多时候可以把检查放在存储过程里,这样有利于我们解读这个存储过程,和排错。
BEGIN TRANSACTION
--事务回滚开始
--检查报错
IF ( @@ERROR > 0 ) BEGIN
--回滚操作
ROLLBACK TRANSACTION RAISERROR('删除工作报告错误', 16, 3) RETURN END
--结束事务
COMMIT TRANSACTION
以上就是详细介绍SQL编程的一些良好好习惯的内容,更多相关内容请关注PHP中文网(www.php.cn)!

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1)タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2)キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3)行はスキャンされた行の数を推定し、クエリのパフォーマンスに影響します。 4)追加の情報を最適化する必要があるというFilesortプロンプトを使用するなど、追加情報を提供します。

Temporaryを使用すると、MySQLクエリに一時テーブルを作成する必要があることが示されています。これは、異なる列、またはインデックスされていない列を使用して順番に一般的に見られます。インデックスの発生を回避し、クエリを書き直し、クエリのパフォーマンスを改善できます。具体的には、expliect出力に使用を使用する場合、MySQLがクエリを処理するために一時テーブルを作成する必要があることを意味します。これは通常、次の場合に発生します。1)個別またはグループビーを使用する場合の重複排除またはグループ化。 2)Orderbyに非インデックス列が含まれているときに並べ替えます。 3)複雑なサブクエリを使用するか、操作に参加します。最適化方法には以下が含まれます。1)OrderbyとGroupB

MySQL/INNODBは、4つのトランザクション分離レベルをサポートしています。 1.ReadunCommittedは、知らないデータを読み取ることができます。 2。読み込みは汚い読み取りを回避しますが、繰り返しのない読みが発生する可能性があります。 3. RepeatablerEadはデフォルトレベルであり、汚い読み取りと非回復不可能な読みを避けますが、幻の読み取りが発生する可能性があります。 4. Serializableはすべての並行性の問題を回避しますが、同時性を低下させます。適切な分離レベルを選択するには、データの一貫性とパフォーマンス要件のバランスをとる必要があります。

MySQLは、Webアプリケーションやコンテンツ管理システムに適しており、オープンソース、高性能、使いやすさに人気があります。 1)PostgreSQLと比較して、MySQLは簡単なクエリと高い同時読み取り操作でパフォーマンスが向上します。 2)Oracleと比較して、MySQLは、オープンソースと低コストのため、中小企業の間でより一般的です。 3)Microsoft SQL Serverと比較して、MySQLはクロスプラットフォームアプリケーションにより適しています。 4)MongoDBとは異なり、MySQLは構造化されたデータおよびトランザクション処理により適しています。

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

MySQL学習パスには、基本的な知識、コアの概念、使用例、最適化手法が含まれます。 1)テーブル、行、列、SQLクエリなどの基本概念を理解します。 2)MySQLの定義、作業原則、および利点を学びます。 3)インデックスやストアドプロシージャなどの基本的なCRUD操作と高度な使用法をマスターします。 4)インデックスの合理的な使用や最適化クエリなど、一般的なエラーのデバッグとパフォーマンス最適化の提案に精通しています。これらの手順を通じて、MySQLの使用と最適化を完全に把握できます。

MySQLの実際のアプリケーションには、基本的なデータベース設計と複雑なクエリの最適化が含まれます。 1)基本的な使用法:ユーザー情報の挿入、クエリ、更新、削除など、ユーザーデータの保存と管理に使用されます。 2)高度な使用法:eコマースプラットフォームの注文や在庫管理など、複雑なビジネスロジックを処理します。 3)パフォーマンスの最適化:インデックス、パーティションテーブル、クエリキャッシュを使用して合理的にパフォーマンスを向上させます。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

VSCode Windows 64 ビットのダウンロード
Microsoft によって発売された無料で強力な IDE エディター

SublimeText3 中国語版
中国語版、とても使いやすい

Dreamweaver Mac版
ビジュアル Web 開発ツール

mPDF
mPDF は、UTF-8 でエンコードされた HTML から PDF ファイルを生成できる PHP ライブラリです。オリジナルの作者である Ian Back は、Web サイトから「オンザフライ」で PDF ファイルを出力し、さまざまな言語を処理するために mPDF を作成しました。 HTML2FPDF などのオリジナルのスクリプトよりも遅く、Unicode フォントを使用すると生成されるファイルが大きくなりますが、CSS スタイルなどをサポートし、多くの機能強化が施されています。 RTL (アラビア語とヘブライ語) や CJK (中国語、日本語、韓国語) を含むほぼすべての言語をサポートします。ネストされたブロックレベル要素 (P、DIV など) をサポートします。

AtomエディタMac版ダウンロード
最も人気のあるオープンソースエディター
