Mysql 一条语句的执行过程（2） 补充

字段名称有误的sql解析

select * from test2 where kkk=2;
有兴趣测了下这个kkk列不存在的时候什么时候出错已了解下对sql的解析过程

对应的代码路径：

Breakpoint 1, dispatch_command (thd=0x7efac40124f0, com_data=0x7efb3a9e2d80, command=COM_QUERY)
    at /root/mysql-5.7.25/sql/sql_parse.cc:1460


mysql_parse (thd=0x7efac40124f0, parser_state=0x7efb3a9e2610) at /root/mysql-5.7.25/sql/sql_parse.cc:5458

mysql_execute_command (thd=0x7efac40124f0, first_level=true) at /root/mysql-5.7.25/sql/sql_parse.cc:2445


execute_sqlcom_select (thd=0x7efac40124f0, all_tables=0x7efac4016bb0)
    at /root/mysql-5.7.25/sql/sql_parse.cc:5099



st_select_lex::prepare (this=0x7efac4015cc0, thd=0x7efac40124f0) at /root/mysql-5.7.25/sql/sql_resolver.cc:97
97	  DBUG_ENTER("SELECT_LEX::prepare");

setup_fields (thd=0x7efac40124f0, ref_pointer_array=..., fields=..., want_privilege=1, 
    sum_func_list=0x7efac4015e20, allow_sum_func=true, column_update=false)
    at /root/mysql-5.7.25/sql/sql_base.cc:8927
	//这步里面没问题

	
	st_select_lex::setup_conds (this=0x7f18ac0058d0, thd=0x7f18ac000b70)
    at /root/mysql-5.7.25/sql/sql_resolver.cc:1154
1154	  DBUG_ENTER("SELECT_LEX::setup_conds");




Item_func::fix_fields (this=0x7f18ac006e80, thd=0x7f18ac000b70, ref=0x7f18ac0059a8)
    at /root/mysql-5.7.25/sql/item_func.cc:213
213	  DBUG_ASSERT(fixed == 0 || basic_const_item());


Item_field::fix_fields (this=0x7f18ac006d60, thd=0x7f18ac000b70, reference=0x7f18ac006f28)
    at /root/mysql-5.7.25/sql/item.cc:5840
5840	  DBUG_ASSERT(fixed == 0);



find_field_in_tables (thd=0x7f18ac000b70, item=0x7f18ac006d60, first_table=0x7f18ac0067c0, last_table=0x0, 
    ref=0x7f18ac006f28, report_error=IGNORE_EXCEPT_NON_UNIQUE, want_privilege=1, register_tree_change=true)
    at /root/mysql-5.7.25/sql/sql_base.cc:7769


	7772	  const char *name= item->field_name;
(gdb) p item->field_name
$145 = 0x7f18ac006440 "kkk"

find_field_in_table_ref (thd=0x7f18ac000b70, table_list=0x7f18ac0067c0, name=0x7f18ac006440 "kkk", length=3, 
    item_name=0x7f18ac006440 "kkk", db_name=0x0, table_name=0x0, ref=0x7f18ac006f28, want_privilege=1, 
    allow_rowid=true, cached_field_index_ptr=0x7f18ac006e38, register_tree_change=true, 
    actual_table=0x7f192c0506a8) at /root/mysql-5.7.25/sql/sql_base.cc:7546
7546	  DBUG_ENTER("find_field_in_table_ref");


find_field_in_table (thd=0x7f18ac000b70, table=0x7f18ac00f6c0, name=0x7f18ac006440 "kkk", length=3, 
    allow_rowid=true, cached_field_index_ptr=0x7f18ac006e38) at /root/mysql-5.7.25/sql/sql_base.cc:7438
7438	  uint cached_field_index= *cached_field_index_ptr;

    Field *cur_field=
      find_field_in_table_ref(thd, cur_table, name, length,
                              item->item_name.ptr(), db, table_name, ref,
                              (thd->lex->sql_command == SQLCOM_SHOW_FIELDS) ?
                                0 : want_privilege,
                              allow_rowid,
                              &(item->cached_field_index),
                              register_tree_change,
                              &actual_table);
							  

这这里循环查找							  
(gdb) n
7464	    for (; *field_ptr; ++field_ptr)
(gdb) n
7465	      if (!my_strcasecmp(system_charset_info, (*field_ptr)->field_name, name))
(gdb) p  (*field_ptr)->field_name
$160 = 0x7f18bc011564 "name"
(gdb) p name
$161 = 0x7f18ac006440 "kkk"

而且发现mysql 的解析器，优化器，执行器感觉代码都在一块。

在sql_parse.cc:7057 parse_sql() 我感觉可以理解是语法和词法分析，但是这步并没有对where 列的判断。
而是在执行的“执行的这里面判断” 这执行的里面还包含了对权限，有没有DDL 等判断。还有优化。
这给人的感觉没有明显的代码的区分，也不知道如何去分别。这部分感觉很乱，而且很复杂。