I'm new to MySQL. So I found someone wrote some SQL in our production environment:
SELECT o.`erp_orders_id`
FROM `erp_orders` o
WHERE o.`orders_status`> 2
AND o.`orders_status`< 5
AND o.`shipmentAutoMatched` IN
(SELECT s.`shipmentID`
FROM `erp_shipment` s
WHERE s.`shipmentScanLocal` = 2)
where s.shipmentID
is int(11)
while o.shipmentAutoMatched
is int(6)
.
This query hits an index
IDX_OR_OR_CU(orders_status, orders_type, currency_type)
While I actually have another index:
IDX_OR_SH(orders_status, shipmentAutoMatched)
which I think could be more efficient. and if I change the IN
directive to numbers like:
IN(10, 11, 12)
the IDX_OR_SH
is correctly hit. so I think the only problem might be about the int(11)
and int(6)
.
So the questions:
int(11)
and int(6)
are both int
and they are actually both stored as an INT32
11 is the display width of the integer column, unlike the characters columns where the number means number of character that can be stored. The number in the parenthesis does not determines the max and min values that can be stored in the integer field. The max and min values that can be stored are always fixed.
The display width is wrapped inside parentheses following the base keyword for the type. For example, INT (4) specifies an integer with the display width of four digits. It is important to note that this attribute does not control the range of value that can be stored in the column.
For everyone who cares about the problem, this is probably a bug of InnoDB since 10 years ago. And it's supposed to get fixed in MySQL 6.0. Unfortunately I'm still using 5.5.
It has nothing to do with int(11) and int(6). Simply all subquery result won't hit parent query's index. Some people says change to JOIN
statement would resolve this issue, but it doesn't seem to work for me though.
I will get back and update the answer when I get something new.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With