-- INDEX (BTree data structure) -- Indexes are used to find values within a specific column more quickly -- MySQL normally searches sequentially through a column -- The longer the column, the more expensive the operation is -- UPDATE takes more time, SELECT takes less time -- Single column index CREATE INDEX last_name_idx ON customers (last_name); -- Multi column index CREATE INDEX last_name_first_name_idx ON customers (last_name, first_name);
This is so cool but I have some questions: 1.) What if the table often UPDATES and also SEARCHES? Does it still applicable to add an INDEXED COLUMN? 2.) If I were to UPDATE a table with one of its column was INDEXED (but I'm not going to UPDATE the INDEXED column nor use it for WHERE condition) does it still affects the processing time? I hope someone will help me clarify. Thank you in advance!
1) You have to find balance between search and update. Typically in data warehouse you would want more indexing (because its used for SELECT statements) while you would want less indexing for Database. Ultimately you would want to find balance in your scenario. 2) This is good question. I am not quite sure. Would like to know answer as well.
super cette petite vidéo notamment nous y retrouvons une explication très développé et simple ce qui facilite l'aprentissage, merci de subvenir a nos besoins d'aprentissage et continuez vos vidéos pour apprendre plus au jeunes comme moi.
How would you "aggregate" those tables? An index is created per table, but let's say you want to perform any kind of Join then you can (likely should) create an index on the secondary keys to help MySQL find the records on the "joined" table. If you want to perform a Union then they are actually two queries being executed in a sequence, both of which could have their own specific keys. I'm not sure about what cenario you're thinking about, let me know if that helps
-- INDEX (BTree data structure)
-- Indexes are used to find values within a specific column more quickly
-- MySQL normally searches sequentially through a column
-- The longer the column, the more expensive the operation is
-- UPDATE takes more time, SELECT takes less time
-- Single column index
CREATE INDEX last_name_idx
ON customers (last_name);
-- Multi column index
CREATE INDEX last_name_first_name_idx
ON customers (last_name, first_name);
❤
Hey bro ! Loving the new style of content+ thumbnails , it's really neat and to the point.
I hit the like button before I even watched the video because I knew I wasn't going to be disappointed, it's Bro code after all😂
You are one of the best teachers on the RUclips
This is so cool but I have some questions:
1.) What if the table often UPDATES and also SEARCHES? Does it still applicable to add an INDEXED COLUMN?
2.) If I were to UPDATE a table with one of its column was INDEXED (but I'm not going to UPDATE the INDEXED column nor use it for WHERE condition) does it still affects the processing time?
I hope someone will help me clarify. Thank you in advance!
1) You have to find balance between search and update. Typically in data warehouse you would want more indexing (because its used for SELECT statements) while you would want less indexing for Database. Ultimately you would want to find balance in your scenario.
2) This is good question. I am not quite sure. Would like to know answer as well.
super cette petite vidéo notamment nous y retrouvons une explication très développé et simple ce qui facilite l'aprentissage, merci de subvenir a nos besoins d'aprentissage et continuez vos vidéos pour apprendre plus au jeunes comme moi.
thanks brother im presenting a cybersecurity project in 4 days and i needed this
Can you please explain indexes on joins and group by etc
You have really came a long way bro
Hi bro, please also upload the videos on Flask
Best video on the ropic
your MySQL workbench platform UI looks very clean! how did you do that ? mine looks very unappealing
can you plz tell me settings options ?
Well Explained❤
Hey bro, nice content
I like the video but it would have been great if you showcased it with a bigger dataset.
Thank you
Is it possible to crate a Index over multiple tables?
For Example if i had two tables with unique keys and aggregate those to get a faster result set?
How would you "aggregate" those tables?
An index is created per table, but let's say you want to perform any kind of Join then you can (likely should) create an index on the secondary keys to help MySQL find the records on the "joined" table.
If you want to perform a Union then they are actually two queries being executed in a sequence, both of which could have their own specific keys.
I'm not sure about what cenario you're thinking about, let me know if that helps
The like counter was at 666. Had to drop a like to change that. Thanks for the video🙏
yoo 2nd
so if i use only the first name, then the last_name_first_name_idx won't be used?