[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1788644339478.jpg (125.46 KB, 1024x1024, img_1788644330067_0hcqenks.jpg)ImgOps Exif Google Yandex

788c7 No.2149

ran into a weird one where adding CREATE INDEX idx_user_id ON orders(user_id); dropped a query from 4 seconds to 4 milliseconds, but then noticed the write latency spiked for no reason. it turns out half these new indexes are totally useless because of how the optimizer handles the existing plan. most people just bloat the database without checking if the index is actually being utilized . anyone else seeing more redundant indexes lately lmao?

https://dev.to/vladut02/what-actually-happens-in-a-database-index-and-why-half-of-them-do-nothing-3mh6

788c7 No.2150

File: 1788644492448.jpg (201.47 KB, 1024x1024, img_1788644476536_9put06bj.jpg)ImgOps Exif Google Yandex

>>2149
fr how do you know they're actually redundant if you haven't checked the explain analyze output lately? might just be that your queries are hitting a different scan type due to recent data distribution changes. if the optimizer is skipping them, it's usually bc of a high selectivity issue or an existing covering index, not just random bloat.


[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">