Remember a MySQL statement execution problem

The table structure is as follows:

mysql> CREATE TABLE `table_a` (
  `id` int(11) NOT NULL,
  `b` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `b` (`b`)
) ENGINE=InnoDB;

Suppose that there are 1 million rows of data in the table now, and the value of b of 100,000 rows of data is '1234567890'. Suppose the current execution statement is written like this:

mysql> select * from table_a where b='1234567890abcd';

At this time, how will MySQL execute?

• Ideally, if MySQL sees that the field b defines varchar(10), it must return null. Unfortunately, MySQL did not do this.
• Or else, just take the '1234567890abcd' into the index to do the matching. It must not be able to quickly determine that there is no such value on the index tree b, and an empty result will be returned soon. But in fact, MySQL does not do this.

 

The execution of this SQL statement is very slow, and the flow is like this:

1. When it is passed to the engine for execution, the character is truncated. Because this line in the engine only defines a length of 10, only the first 10 bytes are truncated, which is '1234567890' to go in for matching;
2. There are 100,000 rows of data that meet the conditions;
3. Because it is select *, it has to return to the table 100,000 times;
4. But every time I go back to the table and find out the entire row, go to the server layer to make a judgment, the value of b is not '1234567890abcd';
5. The return result is empty.