【正文】 pe syntax allows you to make your code more portablebut does this portability e with a cost in terms of performance?Table 192 shows the number of milliseconds needed to insert 1,000 rows into the TESTXXXPERF table. Timings are shown with the SQL92 escape syntax parser on and off for both the OCI and Thin drivers. As before, these timings represent the result of three program runs averaged together. Table 192: SQL92 token parser timings (in milliseconds)SQL92 parserOCIThinOn2,5672,514Off2,7442,550Notice from Table 192 that with the OCI driver we lose 177 milliseconds when escape syntax parsing is turned off, and we lose only 37 milliseconds when the parser is turned off with the Thin driver. These results are the opposite of what you might intuitively expect. It appears that both drivers have been optimized for SQL92 parsing, so you should leave it on for best performance. Now that you know you never have to worry about turning the SQL92 parser off, let39。s not interesting enough to write home about, it does demonstrate how automit can impact performance.Table 191: Automit timings (in milliseconds)AutomitOCIThinOn3,7123,675Off2,6132,594Clearly, it39。s automit feature is on, which means that each SQL statement is mitted as it is executed. If more than one SQL statement is executed by your program, then a small performance increase can be achieved by turning off automit. Let39。alter table TestXXXPerfadd constraint TestXXXPerf_Pkprimary key ( id )using indextablespace users pctfree 20storage( initial 1 M next 1 M pctincrease 0 )。ll use this knowledge to your advantage. Let39。m sure you39。ll not show the code for the examples in this chapter. I39。ll also examine the performance of the OCI versus the Thin driver in each situation to see if, as Oracle39。ll look at the impact of the SQL92 syntax parser. Then we39。ll examine the relative performance of various JDBC objects using example programs that report the amount of time it takes to acplish a given task. We39。s efficiency, you can use the EXPLAIN PLAN facility to explain how the database39。原文一：Java Programming with Oracle JDBC：PerformancePerformance is usually considered an issue at the end of a development cycle when it should really be considered from the , a task called performance tuning is done after the coding is plete, and the end user of a program plains about how long it takes the program to plete a particular net result of waiting until the end of the development cycle to consider performance includes the expense of the additional time required to recode a program to improve its 39。s my opinion that performance is something that is best considered at the start of a project.When it es to performance issues concerning JDBC programming there are two major factors to consider. The first is the performance of the database structure and the SQL statements used against it. The second is the relative efficiency of the different ways you can use the JDBC interfaces to manipulate a database.In terms of the database39。s optimizer plans to execute your SQL statements. Armed with this knowledge, you may determine that additional indexes are needed, or that you require an alternative means of selecting the data you desire.On the other hand, when it es to using JDBC, you need to know ahead of time the relative strengths and weaknesses of using automit, SQL92 syntax, and a Statement versus a PreparedStatement versus a CallableStatement object. In this chapter, we39。ll first look at automit. Next, we39。ll start a series of parisons of the Statement object versus the PreparedStatement object versus the CallableStatement object. At the same time we39。s claims, there is a significant enough performance gain with the OCI driver that you should use it instead of the Thin driver. For the most part, our discussions will be based on timing data for 1,000 inserts into the test performance table TESTXXXPERF. There are separate programs for performing these 1,000 inserts using the OCI driver and the Thin driver. The performance test programs themselves are very simple and are available online with the rest of the examples in this book. However, for brevity, I39。ll only talk about them. Although the actual timing values change from system to system, their relative values, or ratios from one system to another, remain consistent. The timings used in this chapter were gathered using Windows 2000. Using objective data from these programs allows us to e to factual conclusions on which factors improve performance, rather than relying on hearsay.I39。ll be surprised at the reality of performance for these objects, and I hope you39。s get started with a look at the testing framework used in this chapter.A Testing FrameworkFor the most part, the test programs in this chapter report the timings for inserting data into a table. I picked an INSERT statement because it eliminates the performance gain of the database block buffers that may skew timings for an UPDATE, DELETE, or SELECT .The test table used in the example programs in this chapter is a simple relational table. I wanted it to have a NUMBER, a small VARCHAR2, a large VARCHAR2, and a DATE column. Table TESTXXXPERF is defined as:create table TestXXXPerf (id number,code varchar2(30),descr varchar2(80),insert_user varchar2(30),insert_date date )tablespace users pctfree 20storage( initial 1 M next 1 M pctincrease 0 )。The initial extent size used for the table makes it unlikely that the database will need to take the time to allocate another extent during the execution of one of the test programs. Therefore, extent allocation will not impact the timings. Given this background, you should have a context to understand what is done in each section by each test program.AutoCommitBy default, JDBC39。s take a look at some numbers. Table 191 shows the average time, in milliseconds, needed to insert 1,000 rows into th