Microsoft SQL Server 総合スレ 12

1 ：NAME IS NULL：2023/09/21(木) 08:50:54.98 ID:???.net

Microsoft SQL Server (Transact-SQL) の総合スレッドです。

・Microsoft 公式サイト
http://www.microsoft.com/japan/sql/

2 ：NAME IS NULL：2023/09/29(金) 10:19:10.16 ID:???.net

どなたかご存知の方、ご教授お願いします。
SQLSERVER2014を2019(共にSTD)にインプレースアップグレードしました。
その後2014のDBバックアップを2019にリストアしようとすると、以前の数倍掛かる時が出てきました。
また互換性レベルを120に合わせているにも関わらず、2014の時より倍以上遅くなるSQL(ストアド)が見つかり、困っております。
有識者の方、解消のアドバイス宜しくお願い致します。

3 ：NAME IS NULL：2023/09/29(金) 12:27:56.66 ID:???.net

統計情報に一票

ストアドが遅い原因を推測するには
SQL文、テーブル/インデックス構造、2014/2019それぞれでの実行計画と計測した処理時間が必要

4 ：NAME IS NULL：2023/09/29(金) 18:12:42.79 ID:???.net

>>3
コメントありがとうございます！
ストアドについては2014と2019、同じバックアップを復元したあと、全く同じ操作をさせたのですが、統計情報が違って実行プランが変わる可能性があるのですね…確認してみます！

5 ：NAME IS NULL：2023/10/16(月) 13:06:47.40 ID:???.net

これはうれしい誤算だね！

6 ：NAME IS NULL：2023/12/03(日) 23:55:20.02 ID:???.net

tes

7 ：NAME IS NULL：2024/01/26(金) 00:10:54.07 ID:???.net

板ふっとんだんだ
こちらも2014から2019にあげたけど倍速になった
2016？で改善されたinsertスレッドマルチ化がめっちゃ効いてる
統計情報更新とか処理時間7割減で終わるようになってもう俺ごときのエンジニアいらんようになった感、、トラックドライバーにでも転職するかなあ

8 ：NAME IS NULL：2024/03/26(火) 08:14:29.04 ID:ZBkiQq/P.net

すんません、教えて

declare @Kijunbi datetime;
set @Kijunbi = '2024/03/31';

select Jininbi, Shimei from SampleTable where ( Jininbi is null or Jininbi>@Kijunbi );

Jininbi のデータ型はdatetime ですが、上記のSQLだとJininbiが2024/03/31 のデータが取得出来ないです。

@Kijunbiも、取得したいデータのJininbi列の値も
'2024-03-31 00:00:00.000' とかだと思うのですが…

9 ：NAME IS NULL：2024/03/26(火) 08:35:04.38 ID:???.net

ああなんか勘違いしておりました…

10 ：NAME IS NULL：2024/04/06(土) 14:14:49.98 ID:???.net

test