Di satu sisi, ada baiknya Anda membuka pertanyaan baru. Tetapi di sisi lain, dengan mengekstraksi satu kueri dan menanyakan apakah kinerjanya lebih cepat, kehilangan konteks pertanyaan sebelumnya, pertanyaan baru terlalu terisolasi. Seperti yang saya yakin Anda ketahui, mengelola database, mengelola sumber daya (memori/cache, disk, siklus CPU), mengelola kode (baik atau buruk) yang menggunakan sumber daya tersebut, semuanya adalah bagian dari keseluruhan gambaran. Performa adalah permainan perdagangan, tidak ada yang gratis.
-
Masalah utama yang saya miliki, adalah duplikasi kolom EndDate, yang mudah diturunkan. Kolom duplikat sama dengan Perbarui Anomali. Smirkingman telah memberikan contoh klasik:beberapa kueri akan mendapatkan satu hasil dan kueri lainnya akan mendapatkan yang lain. Yang tidak dapat diterima adalah organisasi besar; atau di bank (setidaknya di negara maju) di mana data diaudit dan dilindungi. Anda telah melanggar aturan Normalisasi dasar, dan ada hukuman yang harus dibayar.
-
Perbarui Anomali; dua versi (sudah rinci). Auditor tidak boleh melewati sistem.
-
Ukuran Tabel
Dalam setiap tabel besar itu adalah masalah, dan terutama dalam deret waktu atau data temporal, di mana jumlah kolomnya kecil, dan jumlah barisnya banyak. Jadi apa, beberapa orang akan mengatakan, ruang disk itu murah. Ya, begitu juga PMS. Yang penting adalah untuk apa digunakan, dan seberapa baik seseorang merawatnya.-
Ruang disk
Mungkin murah di PC, tetapi di server produksi tidak. Pada dasarnya Anda telah menambahkan 62% ke ukuran baris (13 ditambah 8 sama dengan 21) dan oleh karena itu ukuran tabel. Di bank tempat saya ditugaskan saat ini, setiap departemen yang memiliki data dikenakan biaya sebagai berikut, hanya ada penyimpanan berbasis SAN. Angka adalah untuk per GB per Bulan (ini bukan bank Aussie kelas atas):$1,05 untuk RAID5 Unmirrored
(kami tahu ini lambat, tapi murah, hanya saja tidak mencantumkan info penting di dalamnya, karena jika rusak, setelah disk baru panas atau dingin ditukar, butuh berhari-hari untuk untuk menyinkronkan ulang sendiri.)$2,10 untuk RAID5 Mirrored
Di SAN, yaitu.$4,40 untuk RAID1+0
Minimum untuk data Produksi, log transaksi yang dicadangkan, dan dump basis data setiap malam.$9,80 untuk RAID1+0 Direplikasi
Ke Tata Letak SAN yang identik di situs lain yang tahan bom. Pemutusan produksi dalam hitungan menit; hampir nol kerugian transaksi. -
Memori/Cache
Ok, Oracle tidak memilikinya tetapi dbs perbankan yang serius memiliki cache, dan mereka dikelola. Mengingat ukuran cache tertentu, hanya 62% baris yang akan masuk ke dalam ukuran cache yang sama. -
Logical &Physical I/O
Yang berarti 50% lebih banyak I/O untuk membaca tabel; baik streaming ke cache dan pembacaan disk.
-
-
-
Oleh karena itu, apakah kueri berkinerja lebih baik atau lebih buruk dalam isolasi, adalah masalah akademis. Dalam konteks di atas, tabel lambat, dan kinerjanya 62% lebih buruk, sepanjang waktu, pada setiap akses. Dan itu mempengaruhi setiap pengguna lain di server. Sebagian besar DBA tidak akan peduli (saya tentu tidak akan peduli) jika bentuk subquery bekerja setengah kecepatan, karena bonus mereka terkait dengan penerimaan audit, bukan hanya kinerja kode.
-
Selain itu, ada manfaat tambahan karena tidak perlu mengunjungi kembali kode, dan memperbaiki transaksi karena Anomali Pembaruan.
-
Dan transaksi memiliki lebih sedikit poin untuk diperbarui, sehingga lebih kecil; lebih sedikit kunci pemblokiran, dll.
-
-
Setuju, bahwa diskusi di Komentar itu sulit. Dalam Jawaban saya, saya telah merinci dan menjelaskan dua subquery. Ada kesalahpahaman:Anda sedang membicarakan subkueri ini (dalam klausa WHERE, subkueri tabel ) dan saya berbicara tentang subkueri lainnya (dalam daftar kolom, sebuah subkueri skalar ) ketika saya mengatakan itu bekerja secepat atau lebih cepat. Sekarang setelah dibersihkan, saya tidak dapat mengatakan bahwa kueri pertama di atas (subquery dalam klausa WHERE, sebuah tabel) akan bekerja secepat kueri kedua (dengan kolom duplikat); yang pertama harus melakukan 3 pemindaian, di mana yang kedua hanya melakukan 2 pemindaian. (Saya berani mengatakan yang kedua akan memindai tabel.)
Intinya, selain masalah isolasi, ini bukan perbandingan yang adil, saya membuat komentar tentang subquery skalar. Saya tidak menyarankan bahwa kueri 3-pindaian secepat atau lebih cepat dari kueri 2-pindaian.
Pernyataan yang saya buat tentang subquery tabel 3-scan (yang saya kutip di sini) perlu diambil dalam konteks penuh (baik itu posting di toto, atau di atas). Saya tidak akan mundur.
Saya menghabiskan separuh hidup saya menghapus alternatif ilegal seperti kolom duplikat, yang didasarkan pada masalah kinerja, dengan pencipta melantunkan mantra meja lambat, sehingga mereka telah "denormalisasi untuk kinerja". Hasilnya, dapat diprediksi sebelum saya mulai, adalah tabel berukuran setengah, yang bekerja dua kali lebih cepat secara keseluruhan . Seri Times adalah pertanyaan paling umum di sini (tautan tertaut ke pertanyaan lain; yang menautkan ke pertanyaan lain), tetapi bayangkan masalahnya dalam basis data perbankan:
OpeningExposureharian danClosingExposureperSecurityperHoldingperUnitTrustperPortfolio. -
Tapi izinkan saya menjawab pertanyaan yang belum ditanyakan. Interaksi semacam ini normal, tidak jarang ketika bekerja dengan tim pengembangan internal; itu muncul setidaknya sebulan sekali. Pengembang crash hot telah menulis dan menguji kodenya, menggunakan tabel dengan kolom duplikat, terbang, dan sekarang macet karena saya tidak akan memasukkannya ke dalam db.
Tidak, saya akan mengujinya dalam konteks keseluruhan sistem dan:
-
separuh waktu, tabel masuk tanpa kolom EndDate karena tidak ada masalah besar tentang kueri setengah detik yang sekarang tampil dalam satu detik.
-
Separuh waktu lainnya, kinerja [table subquery] tidak dapat diterima, jadi saya menerapkan indikator boolean (bit) untuk mengidentifikasi
IsCurrent. Itu jauh lebih baik daripada kolom duplikat, dan memberikan kecepatan 2-scan. -
Tidak dalam sejuta tahun Anda akan membuat saya menduplikasi kolom; menambahkan 62% ke ukuran tabel; memperlambat tabel dalam konteks multi-pengguna penuh sebesar 62%; dan berisiko gagal Audit. Dan saya bukan karyawan, saya tidak mendapatkan bonus.
Sekarang itu akan layak untuk diuji:kueri dengan kolom duplikat vs kueri dengan
IsCurrentindikator, dalam konteks penuh penggunaan sumber daya secara keseluruhan. -
-
Smirkingman telah mengemukakan poin yang bagus. Dan saya akan menyatakan kembali dengan jelas, sehingga tidak terfragmentasi dan kemudian salah satu atau fragmen lainnya diserang. Tolong jangan putuskan ini:
Basis Data Relasional,
Dinormalisasi oleh pemodel Relasional yang berpengalaman, ke Bentuk Normal Kelima yang sebenarnya
(tidak ada Anomali Pembaruan; tidak ada kolom duplikat),
dengan Kepatuhan Relasional penuh
(IDEF1X, khususnya yang berkaitan dengan minimalisasiIdKunci Utama; dan dengan demikian tidak melumpuhkan kekuatan mesin Relasional)
akan menghasilkan lebih banyak tabel yang lebih kecil, database yang lebih kecil,
dengan Indeks yang lebih sedikit,
memerlukan lebih sedikit gabungan
(benar, lebih banyak tabel tetapi lebih sedikit yang bergabung),
dan itu akan mengungguli apa pun yang melanggar salah satu aturan tersebut
pada perangkat keras yang sama,dan perusahaan platform db
(tidak termasuk freeware, MS, Oracle; tapi jangan biarkan hal itu menghentikan Anda),
dalam konteks penuh penggunaan OLTP Produksi
setidaknya satu urutan besarnya,
dan itu akan jauh lebih mudah digunakan
dan diubah
(tidak perlu "memfaktorkan ulang").Saya telah melakukan ini setidaknya 80 kali. Dua kali lipat tidak jarang, jika saya melakukannya sendiri, daripada menyediakan kerangka kerja bagi orang lain untuk melakukannya.
Baik saya, bukan orang yang bekerja dengan saya atau yang membayar saya, tidak peduli apa yang akan dilakukan satu kueri secara terpisah.
