# ## 10.6 Index # Principle ### 10.6.1 index What is an index - a storage table is set up in stages - a storage structure, there can be accelerated when the query index of importance - literacy ratio: 10: 1 reading speed is crucial indexing works - Block disk read-ahead principle - for Line in f storage database - a new data structure ---- tree - balanced tree tree balance - b tree - each node ( and the branch point node) stores not only key also stores data - b + trees: was modified on the basis of b-tree became b + tree: --1 . branch of a root node is not the actual data in storage, so that root and branch node can store more information on the index, reduces the height of the tree, all the actual data is stored in the leaf node - 2 . between leaf nodes to join the two-way chain structure, convenient range of conditions in the query - mysql b + among all the height of the tree index layer is substantially controlled at 3 -What will affect the efficiency index - the height of the tree --1 . On which to create an index column, select the column indexed as short as possible - 2. column indexing of high distinction, repetition rate of more than 10% so not suitable for creating an index clustered index and secondary indexes - clustered index and secondary indexes coexist in innodb - clustered index - primary key (fast): data directly stored in the leaf nodes of the tree structure - do auxiliary primer - all indexes in addition to the primary key It is a secondary index (slow): the species, but leaves the data is not stored directly in a primary key (such as previous data id) and its data link - MyISAM only secondary indexes on how to create an index: create index index name on table (field) deleted index: drop index index name on table name type index - primary key primary key clustered index constraint effect: non-empty + the only - role unique own index secondary index constraint: the only - index secondary indexes no binding effect index is how it works of the SELECT * from table id = the WHERE xxx - inefficient id field when no index -After the id field has an index, high efficiency # ### index hit 10.6.2 reason index is not in force: - a large range of data to be queried - <> = <= =! - the BETWEEN and - like - a large range of results , the index does not take effect - if a - ABC% index into effect,% ABC index does not take effect - if a content discrimination is not high, the index page does not take effect - the index column can no longer condition involved in the calculation - SELECT * from S1 WHERE ID * 10 = 1000000 index does not take effect - to query the contents of two - and : - the SELECT * from s1 the WHERE the above mentioned id = 1000000 and Email = ' eva1000000 @ Oldboy ' ; - across the content and conditions, there is a preference index, and the title of the tree to be queried - both conditions are fulfilled to complete where conditions, to complete a small narrow range of conditions back pressure - or : - or the conditions will not be optimized, but according to the conditions left to right are screened - conditions with or want to hit the index, all columns of these conditions must be indexed column - the SELECT * from s1 the WHERE the above mentioned id = 1000000 or in Email = ' eva1000000 @ Oldboy ' joint index in a joint index if used or conditions index can not take effect - Create index ind_mix oN S1 (ID, in Email) - SELECT * from S1 WHERE ID = 1000000 and in Email = ' eva1000000 @ Oldboy ' ; - the SELECT * fromthe WHERE id = 1000000 s1 or Email = ' eva1000000 @ Oldboy ' most left-prefix principles: first index column (id, name, email) in joint index, the conditions must be contained in the creation of the index, which must contain id go query - the SELECT * from s1 the WHERE the above mentioned id = 1000000 ; hit index - swlect * from s1 the WHERE Email = ' eva1000000 @ Oldboy ' ; not hit index across the condition from blurred matches the beginning of the moment, the index will take effect ( <>% are vague index) - SELECT * from S1 WHERE ID <1000000 and In Email like ' EVA% ' miss - SELECT * from S1 WHERE ID = 1000000 and In Email like ' EVA%' Miss when combined with the index: - only the abc or a condition index, b to c will not be indexed separately when using separate index: - indexing, conditions are selected to distinguish a high column far as small, condition the columns do not participate in the calculation, as a condition of use and connector cover index - if we use the index as a condition for a query, after the query is completed, do not need to check back to the table, covered index - for example: the SELECT the above mentioned id from s1 the WHERE the above mentioned id = 1000000 - Implementation plan: EXPLAIN the SELECT the above mentioned id from s1 the WHERE the above mentioned id = 1000000 What is the index of the merger: two fields to create an index, respectively, due to the condition of sql make two indexes into force at the same time, then this time both indexes has become a merger index # ## 10.7 data backup and services: in the command line, not the database mysqldump -uroot--p123 day40> D: \ code \ day40.sql Affairs: - the begin; # open transaction - the SELECT * from emp the WHERE the above mentioned id = 1for Update; # query id value, for update add row lock; - Update emp the SET salary = 10000 the WHERE id = 1 ; the update is complete - the commit; # commit the transaction # ## 10.8 SQL injection - commented - statement after Wan when a user logs on other people's input in this username, password equivalent to comment out the back of the solution: `` `Python Import pymysql conn = pymysql.connect (Host = ' 127.0.0.1 ' , the user = ' root ' , password = ' 123 ' , Database = ' day41 ' ) CUR = conn.cursor () username = INPUT (' >>> ' ) password = the INPUT ( ' >>>> ' ) SQL = " the SELECT * from UserInfo the WHERE name =% S% S and password = " cur.execute (SQL, (username, password)) # do not own splicing sql statement, the placeholder processing tasks to execute processing Print (cur.fetchone ()) conn.Close () `` `