Timeline for Join query with different column types in "on" part
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2017 at 15:32 | vote | accept | Gonzalo Vasquez | ||
| Nov 27, 2015 at 10:48 | history | edited | Andriy M | CC BY-SA 3.0 |
deleted 2 characters in body
|
| Nov 24, 2015 at 14:07 | history | edited | ypercubeᵀᴹ | CC BY-SA 3.0 |
added 363 characters in body
|
| Nov 24, 2015 at 14:03 | comment | added | ypercubeᵀᴹ |
If you use CONCAT, you are essentially converting the columns from both tables to varchar. No index would be effectively used that way. The query will have to do either 2 full table scans or 2 full index scans.
|
|
| Nov 24, 2015 at 14:01 | comment | added | ypercubeᵀᴹ |
Yeah, which one to use will probably matter if you have some WHERE clause that restricts the number of rows from one of the two tables.
|
|
| Nov 24, 2015 at 13:59 | history | edited | ypercubeᵀᴹ | CC BY-SA 3.0 |
added 363 characters in body
|
| Nov 24, 2015 at 13:58 | comment | added | Gonzalo Vasquez | your edit on using indexes might trim down the rowcount for the join, I'll see what happens with that too | |
| Nov 24, 2015 at 13:57 | history | edited | ypercubeᵀᴹ | CC BY-SA 3.0 |
added 363 characters in body
|
| Nov 24, 2015 at 13:56 | comment | added | Gonzalo Vasquez |
The VIRTUAL column sounds pretty interesting, sounds like mixing a VIEW into the TABLE
|
|
| Nov 24, 2015 at 13:55 | comment | added | Gonzalo Vasquez | Thanks, I'll try that approach, as I was just using plain CONCAT, with a space in between both fields, but didn't seem like the best way to do it | |
| Nov 24, 2015 at 13:47 | history | answered | ypercubeᵀᴹ | CC BY-SA 3.0 |