Bind variables and their pros and cons

bind variable

Refers to using variables instead of constants the sql statement . For example, there are two SQL statements in the shared pool ,

select * from tab1 where col1=1;

select * from tab1 where col1=2;

For the oracle database, these are two completely different SQLs, and hard parse is required for both statements. Because oracle will calculate the hash value of each character in memory according to the text of the sql statement, so although the above two SQLs are only different by one character, the hash address obtained by oracle in memory according to the hash algorithm is different, so oracle will would think that these are two completely different statements. And if the above SQL is rewritten as select * from tab1 where col1=:var1;, and then the query is performed by assigning the variable var1, then Oracle will perform hard parse on this statement for the first time, and then only perform soft parse. Assuming a statement is repeated hundreds of thousands of times, the benefits of using bind var are huge. An application that doesn't use enough bind vars will almost certainly experience severe performance problems.

Bind variables are relative to text variables. The so-called text variables refer to writing query conditions directly in SQL. Such SQL needs to be parsed repeatedly under different conditions. Bind variables refer to using variables instead of directly writing conditions to query the bind value. Passed at runtime, then bound to execute. The advantage is to reduce hard parsing, reduce CPU contention, and save shared_pool; the disadvantage is that histogram cannot be used, and sql optimization is difficult

For every program developer, the knowledge of the database is more or less, and they can write some SQL statements. Even if they don't, they can use some tools to generate SQL statements. Therefore, the database is often considered to be a No research is necessary. As the number of users of the system increased, the system also encountered a bottleneck, so the developers shouted: "Give me memory and CPU, the system will be faster!" However, as a profitable enterprise, investment and return cannot be equivalent, and must be Do more with less investment! Therefore, the development of the database is very important in the preliminary work of the system, and a good database design will improve the scalability of the system.

When the database executes the SQL statement, it will first parse the SQL statement, and the parsing is divided into hard parsing and soft parsing. When it comes to hard parsing and soft parsing, we have to talk about Oracle's processing of sql. When you issue an SQL statement to Oracle, Oracle will process the SQL in several steps before executing and getting the result:

1. Syntax check

　 Check the spelling of this sql is grammatical.

2. Semantic check

   Such as checking whether the access object in the sql statement exists and whether the user has the corresponding permissions.

3. Parse the SQL statement (prase)

   Use internal algorithms to parse sql, generate parse trees and execution plans.

4. Execute sql and return the result (execute and return).

Among them, soft and hard parsing occurs in the third process. Oracle uses the internal hash algorithm to obtain the hash value of the sql, and then checks whether the hash value exists in the librarycache. Assuming it exists, compare this sql with the one in the cache (note that the comparison here will be considered different even if the case of a letter and the number of spaces are inconsistent). Assuming "the same", the existing parse tree and execution plan will be used, and the related work of the optimizer will be omitted. This is also the process of soft parsing; if any of the above two assumptions are not true, the optimizer will create a parse tree and generate an execution plan. This process is called hard parsing. It can be seen from this that hard parsing should be avoided as much as possible, and soft parsing should be used as much as possible.

Is there any way to use soft parsing as much as possible? The answer is: "binding variables, the effect is good". With bind variables, whenever the same query that references the same object is submitted, the compiled query plan from the shared pool is used. In this way, you only need to compile it once and use it repeatedly, and the efficiency will of course be high. This is also the approach the database expects you to take.

Let's look at a simple example, first create a simple table

SQL> create table t (x int);

Then create a stored procedure that uses bind variables to insert data into the T table:

SQL> create or replace procedure pro1

  2 as

  3  begin

  4 for i in 1..10000

  5     loop

  6      execute immediate

  7     'insert into t values(:x)' using i;

  8   end loop;

  9 end;

Then create a stored procedure that does not apply bind variables to query data in the T table:

SQL> create or replace procedure pro2

  2 as

  3 begin

  4 for i in 1..10000

  5     loop

  6      execute immediate

  7     'insert into t values('||i||')';

  8   end loop;

  9 end;

Let's start executing these two stored procedures and check the running time:

SQL> set timing on

SQL> exec pro1;

PL/SQL procedure completed successfully.

Elapsed time: 00: 00: 00.42

SQL> truncate table t; -- this purpose is only related to the execution of the stored procedure pro1 before the T table is empty

Table is truncated.

Elapsed time: 00: 00: 00.20

SQL> exec pro2;

PL/SQL procedure completed successfully.

Elapsed time: 00: 00: 11.53

SQL> set timing off

结果非常明显，使用绑定变量节省的时间可不是一点。这只是个简单的例子，如果在实际应用中那节省的时间将会更多，可能就会造成2个不同性能级别的应用系统。在一个已成型的应用系统中再重新使用绑定变量时费时费力的，你要寻找每个SQL语句，查看是否能使用绑定变量，最重要的是你可能已经提交给客户，这直接影响到客户的满意度。

绑定变量的好处是减少了硬解析，降低了CPU的竞争，节省了shared_pool，但缺点是不能使用柱状图（histogram），SQL优化比较困难。

在系统的研发阶段，应该为数据库设计投入更多的时间，因为所有的数据都是在后台运行的，后台的性能在很大程度上决定了一个系统的性能。

不要以为数据库只有SELECT、INSERT、UPDATE、DELETE，这些只是数据库的基础操作，只是这些简单的操作就需要开发人员增加一些HINT来加快数据的操作，由这些操作还能延伸到数据库的redo日志、undo段的管理等等。数据库并不是一门简单的“语言”，数据库调优与维护更是数据库的精华所在，需要我们学而时习之！