PyMySQL: (*******************************)
. a login authentication
write sql statement when the% transmission value, the need quotes:
sql = "SELECT * from T4 WHERE name = '% S' and pwd = '% S'"% (username, pwd)
above risk is brought sql statement:
Example one:
username = Zekai '#
the SELECT * from T4 the WHERE name =' Zekai '#' and pwd = ''
Example two:
username = dbsahvbdsha 'or 1 = 1 #
the SELECT * from the WHERE T4 name = 'dbsahvbdsha' or 1 = 1
occurs above problems, we call SQL injection (********************************************************** *****)
the root of the problem is:
because too trust user input, lead us to accept user input parameters of time, and no escape for him
to solve the SQL injection:
1. own manual user input value escape
2. execute () automatically filtered
sql = "select * from t4 where name =% s and pwd =% s"
the cursor.execute (SQL, (username, pwd))
# $ ## is inserted into a
cursor.execute (sql, ( 'lxxx' , '1234'))
A plurality of insert ###
Data = [
( 'AAAAA', 'AAA'),
( 'bbbb', 'BBB'),
( 'FFFF', '666'),
( 'rrrr', '888'),
]
cursor.executemany (SQL, the Data)
the try:
cursor.execute (SQL, ( 'LXXX', '1234'))
### deletes and updates when things need to submit
conn.commit ()
the except Exception AS E:
conn. ROLLBACK ()
cursor.lastrowid: the last line of the number of lines
Services: (*********************************************** ************************************************** *)
A set of actions either succeed or fail
properties:
Atomic: a set of operations, either all succeed or fail
consistency (Consistency): refers to transactions that occurred before and after the occurrence of the total data still matches the
isolation (Isolation ): simply put, the operation of a transaction are not visible to other transactions
persistent (durability): when the transaction is completed, its impact should be retained, can not be undone, can only be offset by "other things, opened a" before mistake
The official explanation
A transaction is the basic unit of recovery and concurrency control.
Transaction should have four properties: atomicity, consistency, isolation, durability. These four properties are usually called ACID properties.
Atomicity (atomicity). A transaction is an indivisible unit of work, all operations in the transaction include either do or do not do.
Consistency (consistency). The database transaction must be changed from one consistent state to another consistent state. Consistency and atomicity are closely related.
Isolation (isolation). Execution of a transaction can not be other transactions interference. I.e., operation and use of the data inside a transaction other concurrent transactions are isolated and can not interfere with each other between the respective transaction executed concurrently.
Persistence (durability). Persistent, also known as permanent (permanence), it means that once a transaction commits, changing its data in the database should be permanent. The next operation or other faults should not have any effect on them.
Scene:
thinking:
I go to the bank to a friend money,
I have the card 1,000 yuan,
500 yuan a friend card,
my friend transfer 100 yuan (no fee),
if, cable broken, my money just buckle, but a friend the money was not any extra time, how do?
the Create the Table T11 (
the above mentioned id int Primary Key AUTO_INCREMENT,
name VARCHAR (32) not null default '',
money int not null default 0
) = Engine Innodb charset = utf8;
INSERT INTO T11 (name , money) values ( 'zekai' , 1000), ( 'eagon', 500);
solution:
open a transaction (transaction Start)
(execute sql operation)
the commit: submit the above SQL, let it take effect
rollback: rollback
show full tables; all types
--------------------------------------------- -----------------------------
the following understanding:
view:
the causes:
If there is a SQL statement will be used to frequent , for example:
select * from t4 where id> 12 and id <24;
engage in a map, or an alias
select * from t4 where id> 12 and id <24 ===> v1
View:
SELECT * from V1;
Create View:
Create View v1 as select * from t4 where id > 12 and id <24;
modify the view:
the ALTER view v1 AS SQL statement;
delete view:
drop view v1;
the problem:
If the table data native changed that view will not change ? will change
the data view will not happen to modify the changes do not happen?
scenarios:
MySQL: (DBA)
generated view view
program:
the SELECT * from v1 to call;
function:
Do not use
in the program, calculated by the code, calculate, and then passed to execute SQL statements
stored procedure:
a bunch of SQL statements package, similar to the function, the result is a stored procedure
MySQL server:
DBA (write)
a simple stored procedure:.
DELIMITER //
create procedure p1()
BEGIN
select * from t11;
END //
delimiter ;
程序:
call p1();
b. 传参数: (in)
delimiter //
create procedure p2(
in n1 int,
in n2 int
)
BEGIN
select * from t11 where id > n1;
END //
delimiter ;
程序:
call p2(12, 2)
c. 传入参数: (out)
delimiter //
create procedure p3(
in n1 int,
out n2 int
)
BEGIN
select * from t11 where id > n1;
set n2 = 1;
END //
delimiter ;
set @v2=123212;
call p3(12, @v2);
select @v2;
Trigger:
adding a table to a user data while in the log table also add a record
DELIMITER //
the CREATE TRIGGER the BEFORE the INSERT the ON T1 T7 the FOR EACH the ROW
the BEGIN
INSERT INTO T11 (name, Money) values ( 'XXX', 1234 );
the END //
DELIMITER;