首先，明確一個概念，這個也是之前一直沒怎麼搞清楚的：     log4jdbc一共有三個分支，log4jdbc是原版，最近終於加入Maven的主倉庫中，fork之一是log4jdbc-remix，後來又再fork了一個log4jdbc-log4j2。 這次使用的是：

<dependency>     <groupId>org.lazyluke</groupId>     <artifactId>log4jdbc-remix</artifactId>     <version>0.2.7</version> </dependency>

入門使用方法可以參考本人之前的一篇文章：http://blog.csdn.net/ycpanda/article/details/39769737 一、場景需求 目的：針對經分系統進行sql調優，一般的來說，都是非實時性系統。 通常在dev時，log4jdbc是Info level級，為了方便列印sql除錯。釋出到線上時，就會關閉sql列印，因為太多sql的資訊了，意義不大。 然而，系統執行時，有幾個功能點會載入速度比較慢，如何去優化系統性能，找到慢查詢sql呢？本來想用druid去實現的，但是好幾個老系統難得去修改。然後想到，Log4jdbc-remix不是可以列印每條sql的執行時間麼，如果我去反編譯覆蓋重寫類，然後加入時間判斷條件，不久OK了麼？真為自己機智了一把。

INFO  jdbc.sqltiming - SELECT  xx FROM table R    {executed in 31 msec}

二、動手修改 1、首先，找到了 Slf4jSpyLogDelegator 類，因為這個類有

private final Logger jdbcLogger = LoggerFactory.getLogger("jdbc.audit");
private final Logger resultSetLogger = LoggerFactory.getLogger("jdbc.resultset");
private final Logger resultSetTableLogger = LoggerFactory.getLogger("jdbc.resultsettable");
private final Logger sqlOnlyLogger = LoggerFactory.getLogger("jdbc.sqlonly");
private final Logger sqlTimingLogger = LoggerFactory.getLogger("jdbc.sqltiming");
private final Logger connectionLogger = LoggerFactory.getLogger("jdbc.connection");
private final Logger debugLogger = LoggerFactory.getLogger("log4jdbc.debug");
private static String nl = System.getProperty("line.separator");
 

看到 jdbc.sqltiming ，就知道找到和尚廟了。然後向下翻閱，在333行處：

public void sqlTimingOccured(Spy spy, long execTime, String methodCall, String sql)
  {
    if ((this.sqlTimingLogger.isErrorEnabled()) && ((!DriverSpy.DumpSqlFilteringOn) || (shouldSqlBeLogged(sql))))
    {
      if ((DriverSpy.SqlTimingErrorThresholdEnabled) && (execTime >= DriverSpy.SqlTimingErrorThresholdMsec))
      {
        this.sqlTimingLogger.error(buildSqlTimingDump(spy, execTime, methodCall, sql, true));
      }
      else if (this.sqlTimingLogger.isWarnEnabled())
      {
        if ((DriverSpy.SqlTimingWarnThresholdEnabled) && (execTime >= DriverSpy.SqlTimingWarnThresholdMsec))
        {
          this.sqlTimingLogger.warn(buildSqlTimingDump(spy, execTime, methodCall, sql, true));
        }
        else if (this.sqlTimingLogger.isDebugEnabled())
        {
          this.sqlTimingLogger.debug(buildSqlTimingDump(spy, execTime, methodCall, sql, true));
        }
        else if (this.sqlTimingLogger.isInfoEnabled())
        {
          this.sqlTimingLogger.info(buildSqlTimingDump(spy, execTime, methodCall, sql, false));
        }
      }
    }
  }

有 execTime和sql ，感覺這事要成了。正準備修改，我靠，怎麼會有  execTime >= DriverSpy.SqlTimingWarnThresholdMsec  這種閾值判斷？難道已經實現啦？沒我用武之地？ 2、轉戰到 DriverSpy 類，心裡甚是挖涼--->

private Driver lastUnderlyingDriverRequested;
private static Map rdbmsSpecifics;
static final SpyLogDelegator log = SpyLogFactory.getSpyLogDelegator();
static String DebugStackPrefix;
static boolean TraceFromApplication;
static boolean SqlTimingWarnThresholdEnabled;
static long SqlTimingWarnThresholdMsec;
static boolean SqlTimingErrorThresholdEnabled;
static long SqlTimingErrorThresholdMsec;
static boolean DumpBooleanAsTrueFalse;
static int DumpSqlMaxLineLength;
static boolean StatementUsageWarn;
static boolean DumpSqlSelect;
static boolean DumpSqlInsert;
static boolean DumpSqlUpdate;
static boolean DumpSqlDelete;
static boolean DumpSqlCreate;
static boolean DumpSqlFilteringOn;
static boolean DumpSqlAddSemicolon;
static boolean DumpFullDebugStackTrace;
static boolean AutoLoadPopularDrivers;
static boolean TrimSql;
static boolean SuppressGetGeneratedKeysException;
static RdbmsSpecifics defaultRdbmsSpecifics = new RdbmsSpecifics();

這引數配置咋這多啊，哪裡來的？然後向下找到356行，發現有個靜態塊，然後

log.debug("... log4jdbc initializing ...");
InputStream propStream = DriverSpy.class.getResourceAsStream("/log4jdbc.properties");
Properties props = new Properties(System.getProperties());
//...下面省略了...

不多說了，已哭死。部分邏輯如下：

//......
DebugStackPrefix = getStringOption(props, "log4jdbc.debug.stack.prefix");
TraceFromApplication = DebugStackPrefix != null;

Long thresh = getLongOption(props, "log4jdbc.sqltiming.warn.threshold");
SqlTimingWarnThresholdEnabled = thresh != null;
if (SqlTimingWarnThresholdEnabled)
{
  SqlTimingWarnThresholdMsec = thresh.longValue();
}

thresh = getLongOption(props, "log4jdbc.sqltiming.error.threshold");
SqlTimingErrorThresholdEnabled = thresh != null;
if (SqlTimingErrorThresholdEnabled)
{
  SqlTimingErrorThresholdMsec = thresh.longValue();
}

DumpBooleanAsTrueFalse = getBooleanOption(props, "log4jdbc.dump.booleanastruefalse", false);

DumpSqlMaxLineLength = getLongOption(props, "log4jdbc.dump.sql.maxlinelength", 90L).intValue();

DumpFullDebugStackTrace = getBooleanOption(props, "log4jdbc.dump.fulldebugstacktrace", false);

StatementUsageWarn = getBooleanOption(props, "log4jdbc.statement.warn", false);

DumpSqlSelect = getBooleanOption(props, "log4jdbc.dump.sql.select", true);
DumpSqlInsert = getBooleanOption(props, "log4jdbc.dump.sql.insert", true);
DumpSqlUpdate = getBooleanOption(props, "log4jdbc.dump.sql.update", true);
DumpSqlDelete = getBooleanOption(props, "log4jdbc.dump.sql.delete", true);
DumpSqlCreate = getBooleanOption(props, "log4jdbc.dump.sql.create", true);

DumpSqlFilteringOn = (!DumpSqlSelect) || (!DumpSqlInsert) || (!DumpSqlUpdate) || (!DumpSqlDelete) || (!DumpSqlCreate);

//......

折騰了半天，發現回到了原點。-_-||| 其實在 頁面上都有options的說明，(為了避免大家一起爬牆，貼出來如下)： log4jdbc-log4j2  options

property	default	description
log4jdbc.drivers	One or more fully qualified class names for JDBC drivers that log4jdbc should load and wrap.  If more than one driver needs to be specified here, they should be comma separated with no spaces. This option is not normally needed because most popular JDBC drivers are already loaded by default-- this should be used if one or more additional JDBC drivers that (log4jdbc doesn't already wrap) needs to be included.
log4jdbc.auto.load.popular.drivers	true	Set this to false to disable the feature where popular drivers are automatically loaded. If this is false, you must set the log4jdbc.drivers property in order to load the driver(s) you want.
log4jdbc.debug.stack.prefix	A REGEX matching the package name of your application. The call stack will be searched down to the first occurrence of a class that has the matching REGEX. If this is not set, the actual class that called into log4jdbc is used in the debug output (in many cases this will be a connection pool class.) For example, setting a system property such as this: -Dlog4jdbc.debug.stack.prefix=^com\.mycompany\.myapp.*would cause the call stack to be searched for the first call that came from code in the com.mycompany.myapp package or below, thus if all of your sql generating code was in code located in the com.mycompany.myapp package or any subpackages, this would be printed in the debug information, rather than the package name for a connection pool, object relational system, etc.  Please note that the behavior of this property has changed as compared to the standard log4jdbc implementation. This property is now a REGEX, instead of being just the package prefix of the stack trace. So, for instance, if you want to target the prefix org.mypackage, the value of this property should be: ^org\.mypackage.*.
log4jdbc.sqltiming.warn.threshold	Millisecond time value. Causes SQL that takes the number of milliseconds specified or more time to execute to be logged at the warning level in the sqltiming log. Note that the sqltiming log must be enabled at the warn log level for this feature to work. Also the logged output for this setting will log with debug information that is normally only shown when the sqltiming log is enabled at the debug level. This can help you to more quickly find slower running SQL without adding overhead or logging for normal running SQL that executes below the threshold level (if the logging level is set appropriately.)
log4jdbc.sqltiming.error.threshold	Millisecond time value. Causes SQL that takes the number of milliseconds specified or more time to execute to be logged at the error level in the sqltiming log. Note that the sqltiming log must be enabled at the error log level for this feature to work. Also the logged output for this setting will log with debug information that is normally only shown when the sqltiming log is enabled at the debug level. This can help you to more quickly find slower running SQL without adding overhead or logging for normal running SQL that executes below the threshold level (if the logging level is set appropriately.)
log4jdbc.dump.booleanastruefalse	false	When dumping boolean values in SQL, dump them as 'true' or 'false'. If this option is not set, they will be dumped as 1 or 0 as many databases do not have a boolean type, and this allows for more portable sql dumping.
log4jdbc.dump.sql.maxlinelength	90	When dumping SQL, if this is greater than 0, than the dumped SQL will be broken up into lines that are no longer than this value. Set this value to 0 if you don't want log4jdbc to try and break the SQL into lines this way. In future versions of log4jdbc, this will probably default to 0.
log4jdbc.dump.fulldebugstacktrace	false	If dumping in debug mode, dump the full stack trace. This will result in EXTREMELY voluminous output, but can be very useful under some circumstances when trying to track down the call chain for generated SQL.
log4jdbc.dump.sql.select	true	Set this to false to suppress SQL select statements in the output. Note that if you use the Log4j 2 logger, it is also possible to control select statements output via the marker LOG4JDBC_SELECT (see section "Disabling some SQL operations, or dispatching them in different files" above). The use of this property prepend the use of the marker.
log4jdbc.dump.sql.insert	true	Set this to false to suppress SQL insert statements in the output. Note that if you use the Log4j 2 logger, it is also possible to control insert statements output via the marker LOG4JDBC_INSERT (see section "Disabling some SQL operations, or dispatching them in different files" above). The use of this property prepend the use of the marker.
log4jdbc.dump.sql.update	true	Set this to false to suppress SQL update statements in the output. Note that if you use the Log4j 2 logger, it is also possible to control update statements output via the marker LOG4JDBC_UPDATE (see section "Disabling some SQL operations, or dispatching them in different files" above). The use of this property prepend the use of the marker.
log4jdbc.dump.sql.delete	true	Set this to false to suppress SQL delete statements in the output. Note that if you use the Log4j 2 logger, it is also possible to control delete statements output via the marker LOG4JDBC_DELETE (see section "Disabling some SQL operations, or dispatching them in different files" above). The use of this property prepend the use of the marker.
log4jdbc.dump.sql.create	true	Set this to false to suppress SQL create statements in the output. Note that if you use the Log4j 2 logger, it is also possible to control create statements output via the marker LOG4JDBC_CREATE (see section "Disabling some SQL operations, or dispatching them in different files" above). The use of this property prepend the use of the marker.
log4jdbc.dump.sql.addsemicolon	false	Set this to true to add an extra semicolon to the end of SQL in the output. This can be useful when you want to generate SQL from a program with log4jdbc in order to create a script to feed back into a database to run at a later time.
log4jdbc.spylogdelegator.name	net.sf.log4jdbc.log.log4j2.Log4j2SpyLogDelegator	The qualified class name of the SpyLogDelegator to use. Note that if you want to use log4jdbc-log4j2 with SLF4J rather than Log4j 2, you must set this property to: net.sf.log4jdbc.log.slf4j.Slf4jSpyLogDelegator. This is a new property, not present in the standard log4jdbc implementation.
log4jdbc.statement.warn	false	Set this to true to display warnings (Why would you care?) in the log when Statements are used in the log. NOTE, this was always true in releases previous to 1.2alpha2. It is false by default starting with release 1.2 alpha 2.
log4jdbc.trim.sql	true	Set this to false to not trim the logged SQL. (Previous versions always trimmed the SQL.)
log4jdbc.trim.sql.extrablanklines	true	Set this to false to not trim extra blank lines in the logged SQL ( by default, when more than one blank line in a row occurs, the contiguou lines are collapsed to just one blank line.) (Previous versions didn't trim extra blank lines at all.)
log4jdbc.suppress.generated.keys.exception	false	Set to true to ignore any exception produced by the method, Statement.getGeneratedKeys() (Useful for using log4jdbc with Coldfusion

Of note, an additional property allows to set the name of the property file:

property	default	description
log4jdbc.log4j2.properties.file	log4jdbc.log4j2.properties	Set the name of the property file to use

log4jdbc

property	default	description	since
log4jdbc.drivers	One or more fully qualified class names for JDBC drivers that log4jdbc should load and wrap. If more than one driver needs to be specified here, they should be comma separated with no spaces. This option is not normally needed because most popular JDBC drivers are already loaded by default-- this should be used if one or more additional JDBC drivers that (log4jdbc doesn't already wrap) needs to be included.	1.0
log4jdbc.auto.load.popular.drivers	true	Set this to false to disable the feature where popular drivers are automatically loaded. If this is false, you must set the log4jdbc.drivers property in order to load the driver(s) you want.	1.2beta2
log4jdbc.debug.stack.prefix	The partial (or full) package prefix for the package name of your application. The call stack will be searched down to the first occurrence of a class that has the matching prefix. If this is not set, the actual class that called into log4jdbc is used in the debug output (in many cases this will be a connection pool class.) For example, setting a system property such as this: -Dlog4jdbc.debug.stack.prefix=com.mycompany.myapp Would cause the call stack to be searched for the first call that came from code in the com.mycompany.myapp package or below, thus if all of your sql generating code was in code located in the com.mycompany.myapp package or any subpackages, this would be printed in the debug information, rather than the package name for a connection pool, object relational system, etc.	1.0
log4jdbc.sqltiming.warn.threshold	Millisecond time value. Causes SQL that takes the number of milliseconds specified or more time to execute to be logged at the warning level in the sqltiming log. Note that the sqltiming log must be enabled at the warn log level for this feature to work.  Also the logged output for this setting will log with debug information that is normally only shown when the sqltiming log is enabled at the debug level. This can help you to more quickly find slower running SQL without adding overhead or logging for normal running SQL that executes below the threshold level (if the logging level is set appropriately.)	1.1beta1
log4jdbc.sqltiming.error.threshold	Millisecond time value. Causes SQL that takes the number of milliseconds specified or more time to execute to be logged at the error level in the sqltiming log. Note that the sqltiming log must be enabled at the error log level for this feature to work. Also the logged output for this setting will log with debug information that is normally only shown when the sqltiming log is enabled at the debug level. This can help you to more quickly find slower running SQL without adding overhead or logging for normal running SQL that executes below the threshold level (if the logging level is set appropriately.)	1.1beta1
log4jdbc.dump.booleanastruefalse	false	When dumping boolean values in SQL, dump them as 'true' or 'false'. If this option is not set, they will be dumped as 1 or 0 as many databases do not have a boolean type, and this allows for more portable sql dumping.	1.2alpha1
log4jdbc.dump.sql.maxlinelength	90	When dumping SQL, if this is greater than 0, than the dumped SQL will be broken up into lines that are no longer than this value. Set this value to 0 if you don't want log4jdbc to try and break the SQL into lines this way. In future versions of log4jdbc, this will probably default to 0.	1.2alpha1
log4jdbc.dump.fulldebugstacktrace	false	If dumping in debug mode, dump the full stack trace. This will result in EXTREMELY voluminous output, but can be very useful under some circumstances when trying to track down the call chain for generated SQL.	1.2alpha1
log4jdbc.dump.sql.select	true	Set this to false to suppress SQL select statements in the output.	1.2alpha1
log4jdbc.dump.sql.insert	true	Set this to false to suppress SQL insert statements in the output.	1.2alpha1
log4jdbc.dump.sql.update	true	Set this to false to suppress SQL update statements in the output.	1.2alpha1
log4jdbc.dump.sql.delete	true	Set this to false to suppress SQL delete statements in the output.	1.2alpha1
log4jdbc.dump.sql.create	true	Set this to false to suppress SQL create statements in the output.	1.2alpha1
log4jdbc.dump.sql.addsemicolon	false	Set this to true to add an extra semicolon to the end of SQL in the output. This can be useful when you want to generate SQL from a program with log4jdbc in order to create a script to feed back into a database to run at a later time.	1.2alpha1
log4jdbc.statement.warn	false	Set this to true to display warnings (Why would you care?) in the log when Statements are used in the log. NOTE, this was always true in releases previous to 1.2alpha2. It is false by default starting with release 1.2 alpha 2.	1.2alpha2
log4jdbc.trim.sql	true	Set this to false to not trim the logged SQL. (Previous versions always trimmed the SQL.)	1.2beta2
log4jdbc.trim.sql.extrablanklines	true	Set this to false to not trim extra blank lines in the logged SQL (by default, when more than one blank line in a row occurs, the contiguous lines are collapsed to just one blank line.) (Previous versions didn't trim extra blank lines at all.)	1.2
log4jdbc.suppress.generated.keys.exception	false	Set to true to ignore any exception produced by the method, Statement.getGeneratedKeys()  (Useful for using log4jdbc with Coldfusion.)	1.2beta2

so,一切都柳暗花明了。 三、如何在工程中實現 1、對於maven工程，在src/main/resources下新增一個配置檔案： log4jdbc.properties 內容如下：

#只顯示含呼叫棧的包名的語句 #log4jdbc.debug.stack.prefix= #這2個是在一起的,和資料庫驅動有關。實際作用本人未嘗試 #log4jdbc.auto.load.popular.drivers=true #log4jdbc.drivers= #執行時間閥值，單位為ms，將Log級別調為Warning，則只會列印執行較慢的語句 log4jdbc.sqltiming.warn.threshold=2000 #log4jdbc.sqltiming.error.threshold= #是把boolean記錄為 'true'/'false' 還是 1/0. 預設設定為false,不啟用,為了移植性. #log4jdbc.dump.booleanastruefalse= #輸出的sql,一行最大的字元數，預設90. 以後新版可能為0 #log4jdbc.dump.sql.maxlinelength=90 #If dumping in debug mode, dump the full stack trace. 預設false #log4jdbc.dump.fulldebugstacktrace=false #是否記錄某些型別的語句，預設true #log4jdbc.dump.sql.select=true #log4jdbc.dump.sql.insert=true #log4jdbc.dump.sql.update=true #log4jdbc.dump.sql.delete=true #log4jdbc.dump.sql.create=true #輸出sql末尾處加入分號，預設false #log4jdbc.dump.sql.addsemicolon= #預設true， #log4jdbc.trim.sql=true #display warnings in the log when Statements are used in the log. 預設false,不是太理解 #log4jdbc.statement.warn=false #gnore any exception produced by the method, Statement.getGeneratedKeys() .預設false #log4jdbc.suppress.generated.keys.exception=false

在上面，只設置了warn閾值，其它預設。 2、修改日誌檔案配置：(本處使用的是logback)

<!-- 指定logger的設定，additivity指示是否遵循預設的繼承機制--> <logger name='jdbc.sqltiming' additivity='true' level="warn"/> <logger name='jdbc.audit' additivity='false'/> <logger name='jdbc.resultset' additivity='false'/> <logger name='jdbc.connection' additivity='false'/> <logger name='jdbc.resultsettable' additivity='false'/> <logger name="jdbc.sqlonly" additivity="false"/>

然後，會發現工程console中，sql列印少了很多很多。 但是這種固定配置，在dev時開發時，會不方便除錯，所以我們要用maven profile，進行自動打包配置。實現在dev時，level='info'，產品環境時，level='warn'。 打包請參考：