MySQL: query executed differently in different environments - mysql

Question

I'm creating a bunch of tables in a makefile. My make target looks something like:
TASK:
cat script.sql | mysql -v -v -v dbName
Inside script.sql, one of the create table commands hangs indefinitely with the mysql process at 100% CPU.
If I run the same command as the same user on the same machine but from the command-line, it runs fine.
$ cat script.sql | mysql -v -v -v dbName
Delving into it a bit more, it turns out that explain yields different results in the two environments.
From inside make:
+----+-------------+-------+--------+---------------+---------+---------+----------------------------------------+------+----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------------------+------+----------------------------------------------------+
| 1 | SIMPLE | o | ALL | NULL | NULL | NULL | NULL | 2340 | NULL |
| 1 | SIMPLE | d | index | NULL | PRIMARY | 3 | NULL | 2739 | Using index; Using join buffer (Block Nested Loop) |
| 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 7 | db1.o.field1,db3.d.date | 1 | Using where |
| 1 | SIMPLE | n | ALL | PRIMARY | NULL | NULL | NULL | 1 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------------------+------+----------------------------------------------------+
From the command-line:
+----+-------------+-------+--------+---------------+---------+---------+----------------------------------------+------+----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------------------+------+----------------------------------------------------+
| 1 | SIMPLE | o | ALL | NULL | NULL | NULL | NULL | 2340 | NULL |
| 1 | SIMPLE | d | index | NULL | PRIMARY | 3 | NULL | 2739 | Using index; Using join buffer (Block Nested Loop) |
| 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 7 | db1.o.field1,db3.d.date | 1 | Using where |
| 1 | SIMPLE | n | ref | PRIMARY | PRIMARY | 4 | db2.p.field1 | 1 | Using where |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------------------+------+----------------------------------------------------+
Some digging directed me to this question, and running analyze on one of the tables involved does solve the issue.
But seriously, what is going on here? Is there some environment variable causing mysql to behave differently?
The query in question looks like this:
drop view if exists v;
create view v as (
select *
from db1.order o
cross join db3.dates d
left join db2.price p on (1=1
and p.id = o.id
and p.date = d.date
and p.volume > 0)
left join db3.security n on (1=1
and n.id = p.id
and n.date <= d.date)
);
explain select * from v;
analyze table n;
explain select * from v;
create table t (
primary key (date asc, id asc)
) as (
select * from v
);
From inside make, the first explain yields the first result above, then the analyze causes the second explain to yield the second result above.

Answer 1

It is suspicious of script.sql equality. According to your EXPLAIN output.
JOIN order is same each other, but referenced table of third table 'p' is different.
When executed in shell, 'p' references 'db3.d' but in Make, 'p' references 'db2.d'
That's why I am suspicious.
can you post your query? if confidential, rename table, column. if there is sub-query, more than 2 table alias can be there. but it looks like that there is no sub-query.
this question you gave me is not related yours. he has new environment and ANALYZE is required for table statistics is changed.
to figure out two sql is really same turn on General log. it's simple. add SET GLOBAL general_log = 'ON' at 1st line of script.sql, and SET GLOBAL general_log = 'OFF' at end of sql.
what do you think about my opinion?
UPDATED
Ok, script.sql cleared of suspicion. Then I have no idea why two run differently. MySQL forums may help you.
BTW, I can tell you some information.
how script.sql work? CREATE VIEW and SELECT .. FROM view are part of or whole of script.sql. Is there creation or insertion on db3.security or other tables? If you post MySQL forum, It would be better described how script.sql work.
USE INDEX Did you try EXPLICITLY use of USE INDEX? most inner table 'n' is doing full scan.
innodb_stats_sample_pages Finally set innodb_stats_sample_pages=64 in my.cnf (default is 8), if you use InnoDB. When innodb table is opened, MySQL read 8 random pages, these page is used to aggregate statistics on table (this statistics used to cost of join). So statistics may change every table opening (it's read random page). more sample pages accurate Statistics.
(sorry for my poor English)