來源： https://plantegg.github.io/2020/07/03/MySQL%20JDBC%20StreamResult%20%E5%92%8C%20net_write_timeout/

MySQL JDBC StreamResult 和 net_write_timeout

MySQL JDBC 拉取數據的三種方式

MySQL JDBC 在從 MySQL 拉取數據的時候有三種方式：

1. 簡單模式，也就是預設模式，數據都先要從MySQL Server發到client的OS TCP buffer，然後JDBC把 OS buffer讀取到JVM記憶體中，讀取到JVM記憶體的過程中憋著不讓client讀取，全部讀完再通知inputStream.read(). 數據大的話容易導致JVM OOM
2. useCursorFetch=true，配合FetchSize，也就是MySQL Server把查到的數據先緩存到本地磁碟，然後按照FetchSize挨個發給client。這需要占用MySQL很高的IOPS（先寫磁碟緩存），其次每次Fetch需要一個RTT，效率不高。
3. Stream讀取，Stream讀取是在執行SQL前設置FetchSize：statement.setFetchSize(Integer.MIN_VALUE)，同時確保游標是只讀、向前滾動的（為游標的預設值），MySQL JDBC內置的操作方法是將Statement強制轉換為：com.mysql.jdbc.StatementImpl，調用其方法：enableStreamingResults()，這2者達到的效果是一致的，都是啟動Stream流方式讀取數據。這個時候MySQL不停地發數據，inputStream.read()不停地讀取。一般來說發數據更快些，很快client的OS TCP recv buffer就滿了，這時MySQL停下來等buffer有空閑就繼續發數據。等待過程中如果超過 net_write_timeout MySQL就會報錯，中斷這次查詢。

從這裡的描述來看，數據小的時候第一種方式還能接受，但是數據大了容易OOM，方式三看起來不錯，但是要特別註意 net_write_timeout。

1和3對MySQL Server來說處理上沒有啥區別，也感知不到這兩種方式的不同。只是對1來說從OS Buffer中的數據複製到JVM記憶體中速度快，JVM攢多了數據記憶體就容易爆掉；對3來說JDBC一條條將OS Buffer中的數據複製到JVM(記憶體複製速度快)同時返回給execute挨個處理（慢），一般來說挨個處理要慢一些，這就導致了從OS Buffer中複製數據較慢，容易導致 TCP Receive Buffer滿了，那麼MySQL Server感知到的就是TCP 傳輸視窗為0了，導致暫停傳輸數據。

在數據量很小的時候方式三沒什麼優勢，因為總是多一次set net_write_tiemout，也就是多了一次RTT。

MySQL timeout

1. Creates a statement by calling Connection.createStatement().
2. Calls Statement.executeQuery().
3. The statement transmits the Query to MySqlServer by using the internal connection.
4. The statement creates a new timeout-execution thread for timeout process.
5. For version 5.1.x, it changes to assign 1 thread for each connection.
6. Registers the timeout execution to the thread.
7. Timeout occurs.
8. The timeout-execution thread creates a connection that has the same configurations as the statement.
9. Transmits the cancel Query (KILL QUERY “connectionId“) by using the connection.

參考《揭秘JDBC超時機制》

net_read_timeout

The number of seconds to wait for more data from a connection before aborting the read. When the server is reading from the client, net_read_timeout is the timeout value controlling when to abort.

如下圖，MySQL Server監聽3017埠，195228號包 客戶端發一個SQL 給 MySQL Server，但是似乎這個時候正好網路異常，30秒鐘後（從 SQL 請求的前一個 ack 開始算，Server應該一直都沒有收到），Server 端觸發 net_read_timeout 超時異常（疑問：這裡沒有 net_read_timeout 描述的讀取了一半的現象）

解決方案：建議調大 net_read_timeout 以應對可能出現的網路丟包

net_write_timeout

show processlist 看到的State的值一直處於“Sending to client”，說明SQL這個語句已經執行完畢，而此時由於請求的數據太多，MySQL不停寫入net buffer，而net buffer又不停的將數據寫入服務端的網路棧，伺服器端的網路棧（socket send buffer）被寫滿了，又沒有被客戶端讀取並消化，這時讀數據的流程就被MySQL暫停了。直到客戶端完全讀取了服務端網路棧的數據，這個狀態才會消失。

先看下 net_write_timeout的解釋：The number of seconds to wait for a block to be written to a connection before aborting the write. 只針對執行查詢中的等待超時，網路不好，tcp buffer滿了（應用遲遲不讀走數據）等容易導致mysql server端報net_write_timeout錯誤，指的是mysql server hang在那裡長時間無法發送查詢結果。

報這個錯就是RDS等了net_write_timeout這麼久沒寫數據，可能是客戶端卡死沒有讀走數據，也可能是從多個分片挨個拉取，還沒開始拉第7片前面6片拉取耗時就超過了net_write_timeout。

案例：DRDS 到 MySQL 多個分片拉取數據生成了許多 cursor 併發執行,但拉數據的時候是串列拉取的,如果用戶端拉取數據過慢會導致最後一個 cursor 執行完成之後要等待很久.會超過 MySQL 的 net_write_timeout 配置從而引發報錯. 也就是最後一個cursor打開後一直沒有去讀取數據，直到MySQL Server 觸發 net_write_timeout 異常

首先可以嘗試在 DRDS jdbcurl 配置 netTimeoutForStreamingResults 參數,設置為 0 可以使其一直等待,或設置一個合理的值(秒).

從JDBC驅動中可以看到，當調用PreparedStatement的executeQuery() 方法的時候，如果我們是去獲取流式resultset的話，就會預設執行SET net_write_timeout= ？ 這個命令去重新設置timeout時間。源代碼如下：

而 this.connection.getNetTimeoutForStreamingResults() 預設是600秒，或者在JDBC連接串種通過屬性 netTimeoutForStreamingResults 來指定。

netTimeoutForStreamingResults 預設值：

What value should the driver automatically set the server setting ‘net_write_timeout’ to when the streaming result sets feature is in use? Value has unit of seconds, the value “0” means the driver will not try and adjust this value.

一般在數據導出場景中容易出現 net_write_timeout 這個錯誤，比如這個錯誤堆棧：

或者：

特別註意

JDBC驅動報如下錯誤

Application was streaming results when the connection failed. Consider raising value of ‘net_write_timeout’ on the server. - com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Application was streaming results when the connection failed. Consider raising value of ‘net_write_timeout’ on the server.

不一定是 net_write_timeout 設置過小導致的，JDBC 在 streaming 流模式下只要連接異常就會報如上錯誤，比如：

• 連接被 TCP reset
• 連接因為某種原因(比如 QueryTimeOut、比如用戶監控kill 慢查詢) 觸發 kill Query導致連接中斷

比如出現內核bug，內核卡死不發包的話，客戶端同樣報 net_write_timeout 錯誤

max_allowed_packet: 單個SQL或者單條記錄的最大大小

一些其他的 Timeout

connectTimeout：表示等待和MySQL資料庫建立socket鏈接的超時時間，預設值0，表示不設置超時，單位毫秒，建議30000。 JDBC驅動連接屬性

queryTimeout：超時後jdbc驅動觸發新建一個連接來發送一個 kill 給DB

socketTimeout：JDBC參數，表示客戶端發送請求給MySQL資料庫後block在read的等待數據的超時時間，linux系統預設的socketTimeout為30分鐘，可以不設置。socketTimeout 超時不會觸發發kill，只會斷開連接。

要特別註意socketTimeout僅僅是指等待socket數據時間，如果在傳輸數據那麼這個值就沒有用了。socketTimeout通過mysql-connector中的NativeProtocol最終設置在socketOptions上

static final int SO_TIMEOUT。 Set a timeout on blocking Socket operations:

ServerSocket.accept();
SocketInputStream.read();
DatagramSocket.receive();

The option must be set prior to entering a blocking operation to take effect. If the timeout expires and the operation would continue to block, java.io.InterruptedIOException is raised. The Socket is not closed in this case.

Statement Timeout：用來限制statement的執行時長，timeout的值通過調用JDBC的java.sql.Statement.setQueryTimeout(int timeout) API進行設置。不過現在開發者已經很少直接在代碼中設置，而多是通過框架來進行設置。

max_execution_time：The execution timeout for SELECT statements, in milliseconds. If the value is 0, timeouts are not enabled. MySQL 屬性，可以set修改，一般用來設置一個查詢最長不超過多少秒，避免一個慢查詢一直在跑，跟statement timeout對應。

wait_timeout The number of seconds the server waits for activity on a noninteractive connection before closing it. MySQL 屬性，一般設置tcp keepalive後這個值基本不會超時（這句話存疑 202110）。

On thread startup, the session wait_timeout value is initialized from the global wait_timeout value or from the global interactive_timeout value, depending on the type of client (as defined by the CLIENT_INTERACTIVE connect option to mysql_real_connect()). See also interactive_timeout.

一般來說應該設置： max_execution_time/statement timeout < Tranction Timeout < socketTimeout

SocketTimeout

這個 httpclient 的bug 就是在 TCP 連接握手成功(只受ConnectTimeout影響，SocketTimeout還不起作用)後，還需要進行 SSL的數據交換(HandShake)，但因為httpclient是在連接建立後(含 SSL HandShake)才設置的 SocketTimeout，導致在SSL HandShake的時候卡在了讀數據，此時恰好還沒設置SocketTimeout，導致連接永久卡死在SSL HandShake的讀數據

所以代碼的fix方案就是在建連接前就設置好 SocketTimeout。

一次PreparedStatement 執行

useServerPrepStmts=true&cachePrepStmts=true

5.0.5版本後的驅動 useServerPrepStmts 預設值是false；另外跨Statement是沒法重用PreparedStatement預編譯的，還需要設置 cachePrepStmts 才可以。

對於打開預編譯的URL（String url = “jdbc:mysql://localhost:3306/studb?useServerPrepStmts=true&cachePrepStmts=true“）獲取資料庫連接之後，本質是獲取預編譯語句 pstmt = conn.prepareStatement(sql)時會向MySQL服務端發送一個RPC，發送一個預編譯的SQL模板（驅動會拼接MySQL預編譯語句prepare s1 from ‘select from user where id = ?’），然會MySQL服務端會編譯好收到的SQL模板，再會為此預編譯模板語句分配一個 serverStatementId發送給JDBC驅動，這樣以後PreparedStatement就會持有當前預編譯語句的服務端的serverStatementId,並且會把此 PreparedStatement緩存在當前資料庫連接中，以後對於相同SQL模板的操作 pstmt.executeUpdate()，都用相同的PreparedStatement，執行SQL時只需要發送 serverStatementId *和參數，節省一次SQL編譯, 直接執行。並且對於每一個連接(驅動端及MySQL服務端)都有自己的prepare cache,具體的源碼實現是在com.mysql.jdbc.ServerPreparedStatement中實現。

根據SQL模板和設置的參數，解析成一條完整的SQL語句，最後根據MySQL協議，序列化成位元組流，RPC發送給MySQL服務端

準備好需要發送的MySQL協議的位元組流（sendPacket）後，就可以一路通過ConnectionImpl.execSQL –> MysqlIO.sqlQueryDirect –> MysqlIO.send – > OutPutStram.write把位元組流數據通過Socket發送給MySQL伺服器，然後線程阻塞等待服務端返回結果數據，拿到數據後再根據MySQL協議反序列化成我們熟悉的ResultSet對象。

案例

設置JDBC參數不合理（不設置的話預設值是：queryTimeout=10s，socketTimeout=10s），會導致在異常情況下，第二條get獲得了第一條的結果，拿到了錯誤的數據，資料庫則表現正常

socketTimeout觸發後，連接拋CommunicationsException（嚴重異常，觸發後連接應該斷開）, 但JDBC會檢查請求是否被cancle了，如果cancle就會拋出MySQLTimeoutException異常，這是一個普通異常，連接會被重新放回連接池重用（導致下一個獲取這個連接的線程可能會得到前一個請求的response）。

queryTimeout（queryTimeoutKillsConnection=True–來強制關閉連接）會觸發啟動一個新的連接向server發送 kill id的命令，MySQL5.7增加了max_statement_time/max_execution_time來做到在server上直接檢測到這種查詢，然後結束掉。

jdbc 和 RDS之間 socket_timeout

jdbc驅動設置socketTimeout=1459，如果是socketTimeout觸發客戶端斷開後，server端的SQL會繼續執行，如果是client被kill則server端的SQL會被終止

對應抓包，沒有 kill動作

CN 和 DN 間socket_timeout案例

設置CN到DN的socket_timeout為2秒，然後執行一個sleep

CN上抓包分析(stream 5是客戶端到CN、stream6是CN到DN）如下，首先CN會計時2秒鐘後發送quit給DN，然後斷開和DN的連接，並返回一個錯誤給client，client發送quit斷開連接：

CN完整報錯堆棧：

應用和 DB 間丟包導致 keepalive 心跳失敗

應用使用了 Druid 連接池來維護到 DB 間的所有長連接

應用和 DB 間丟包導致 keepalive 心跳失敗，進而 OS會斷開這個連接

一個連接歸還給Druid連接池都要做清理動作，就是第一個紅框的rollback/autocommit=1

歸還後OS 層面會探活TCP 連接，DB(4381)多次後多次不響應後，OS 觸發reset tcp斷開連接，此時上次應用(比如Druid連接池、比如Tomcat)還不知道此連接在OS 層面已經斷開

繼續過來一個新連接，業務取到這個連接執行查詢就會報如下錯誤：

這個錯誤就是因為OS層面連接斷開了，並且斷開了162秒(和截圖時間戳能對應上)

對應的錯誤堆棧：

kill 案例

kill mysql client

mysql client連cn執行一個很慢的SQL，然後kill掉mysql client

cn報錯：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

2022-06-01 11:45:59.063 [ServerExecutor-bucket-0-17-thread-158] ERROR com.alibaba.druid.pool.DruidPooledStatement - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] CommunicationsException, druid version 1.1.24, jdbcUrl : jdbc:mysql://172.16.40.215:3008/bank_000000?maintainTimeStats=false&rewriteBatchedStatements=false&failOverReadOnly=false&cacheResultSetMetadata=true&allowMultiQueries=true&clobberStreamingResults=true&autoReconnect=false&usePsMemOptimize=true&useServerPrepStmts=true&netTimeoutForStreamingResults=0&useSSL=false&metadataCacheSize=256&readOnlyPropagatesToServer=false&prepStmtCacheSqlLimit=4096&connectTimeout=5000&socketTimeout=9000000&cachePrepStmts=true&characterEncoding=utf8&prepStmtCacheSize=256, testWhileIdle true, idle millis 72028, minIdle 5, poolingCount 4, timeBetweenEvictionRunsMillis 60000, lastValidIdleMillis 345734, driver com.mysql.jdbc.Driver, exceptionSorter com.alibaba.polardbx.common.jdbc.sorter.MySQLExceptionSorter 2022-06-01 11:45:59.064 [ServerExecutor-bucket-0-17-thread-158] ERROR com.alibaba.druid.pool.DruidDataSource - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] discard connection com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at com.mysql.jdbc.Util.handleNewInstance(Util.java:425) ………… at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223) at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60) Caused by: java.net.SocketException: Socket is closed at java.net.Socket.getSoTimeout(Socket.java:1291) at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:249) at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208) at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659) ... 53 common frames omitted 2022-06-01 11:45:59.065 [ServerExecutor-bucket-0-17-thread-158] WARN com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] [TDDL] [1461c86bbe809001]Execute ERROR on GROUP: BANK_000000_GROUP, ATOM: dskey_bank_000000_group#pxc-xdb-s-pxcunrcbmk4g9lcpk0f24#172.16.40.215-3008#bank_000000, MERGE_UNION_SIZE:1, SQL: /*DRDS /10.101.32.6/1461c86bbe809001/0// */SELECT SLEEP(?) AS `sleep(236)`, PARAM: [236], ERROR: Communications link failure, tddl version: 5.4.13-16522656 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ………… at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60) Caused by: java.net.SocketException: Socket is closed at java.net.Socket.getSoTimeout(Socket.java:1291) at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:249) at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208) at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659) ... 53 common frames omitted 2022-06-01 11:45:59.065 [ServerExecutor-bucket-0-17-thread-158] WARN com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] [TDDL] Reset conn socketTimeout failed, lastSocketTimeout is 9000000, tddl version: 5.4.13-16522656 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ………… at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223) at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60) 2022-06-01 11:45:59.065 [ServerExecutor-bucket-0-17-thread-158] WARN com.alibaba.polardbx.executor.ExecutorHelper - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] [TDDL] PhyQuery(node="BANK_000000_GROUP", sql="SELECT SLEEP(?) AS `sleep(236)`") , tddl version: 5.4.13-16522656 2022-06-01 11:45:59.066 [ServerExecutor-bucket-0-17-thread-158] ERROR com.alibaba.polardbx.server.ServerConnection - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] [TDDL] Interrupted unexpectedly for 1461c86bbe809001, tddl version: 5.4.13-16522656 java.lang.InterruptedException: null at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1310) at com.alibaba.polardbx.common.utils.BooleanMutex$Sync.innerGet(BooleanMutex.java:136) at com.alibaba.polardbx.common.utils.BooleanMutex.get(BooleanMutex.java:53) at com.alibaba.polardbx.common.utils.thread.ServerThreadPool.waitByTraceId(ServerThreadPool.java:445) at com.alibaba.polardbx.server.ServerConnection.innerExecute(ServerConnection.java:1291) …… at com.alibaba.wisp.engine.WispTask.access$100(WispTask.java:33) at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223) at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60) 2022-06-01 11:45:59.066 [ServerExecutor-bucket-0-17-thread-158] WARN com.alibaba.polardbx.server.ServerConnection - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] [TDDL] [ERROR-CODE: 3009 您的分享是我們最大的動力! -Advertisement- 更多相關文章 dotnet 推薦 LightWorkFlowManager 輕量的工作過程管理庫 本以為跟國際化無緣，不在軟體的考慮範圍內，沒想到偶爾一個項目還是繞不開，小記一下System.Globalization.CultureInfo.InstalledUICulture.Name 這是獲得英文的區域碼，也就是zh-cn的這種，需要找區域碼字典對照。 System.Globalizati ... Linux p3 遠程操作Linux 【學習課程】：【【小白入門 通俗易懂】2021韓順平 一周學會Linux】 https://www.bilibili.com/video/BV1Sv411r7vd/?p=14&share_source=copy_web&vd_source=2c07d62293f5003c919b2df9b2e054 ... OpenSSL 生成 RootCA （根證書）並自簽署證書（支持 IP 地址） 背景 某機房內部訪問需要配置 HTTPS，網上找的一些證書教程都不是特別好，有些直接生成證書，沒有根 CA 的證書導致信任不了 Ubuntu 機器，有些教程只有功能變數名稱生成，沒有 IP 生成，有些甚至報錯。故發一個筆者在 Ubuntu 22.04 機器上測試正確可用的流程，這裡使用 10.12.0.2 ... 9-Linux 操作系統軟體的安裝方式 說明：在Linux CentOS系統中，軟體的管理方式有三種：rpm、yum、編譯方式。 一、rpm 優點：對於軟體包的操作比較簡單，通過簡單指令即可操作 缺點： ①安裝時需要自行下載軟體包 ②安裝、卸載軟體時需要考慮到依賴關係 ③軟體的自定義性比較差，不適合有特殊需求的場景 語法 ①查詢 #rpm ... Windows更改電腦上的遠程桌面的偵聽埠 更改電腦上的遠程桌面的偵聽埠 轉載：https://learn.microsoft.com/zh-CN/windows-server/remote/remote-desktop-services/clients/change-listening-port 適用範圍：Windows Server ... 從內核世界透視 mmap 記憶體映射的本質（源碼實現篇） 本文基於內核 5.4 版本源碼討論 通過上篇文章 《從內核世界透視 mmap 記憶體映射的本質（原理篇）》的介紹，我們現在已經非常清楚了 mmap 背後的映射原理以及它的使用方法，其核心就是在進程虛擬記憶體空間中分配一段虛擬記憶體出來，然後將這段虛擬記憶體與磁碟文件映射起來，整個 mmap 系統調用就結束了 ... 2023_10_10_MYSQL_DAY_02_筆記 2023_10_10_MYSQL_DAY_02_筆記 #在 FROM 子句中使用子查詢 SELECT a.ename, a.sal, a.deptno, b.salavg FROM emp a, (SELECT deptno, AVG(sal) salavg FROM emp GROUP BY de ... MySQL業務用戶無法修改的會話級別參數 如今，大規模、高時效、智能化數據處理已是“剛需”，企業需要更強大的數據平臺，來應對數據查詢、數據處理、數據挖掘、數據展示以及多種計算模型並行的挑戰，湖倉一體方案應運而生。 《實時湖倉實踐五講》是袋鼠雲打造的系列直播活動，將圍繞實時湖倉的建設趨勢和通用問題，邀請奮戰於企業數字化一線的核心產品&技術專家 ... 一周排行 -Advertisement- 移動開發（一）：使用.NET MAUI開發第一個安卓APP 移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ... wpf ToggleButton選中效果和一個登錄界面 前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ... 彈幕樹洞項目功能新增篇 項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ... 第27篇 sqlserver2022詳細安裝步驟 話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ... .NET 開源高性能 MQTT 類庫 前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ... Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出 Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ... 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ... [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一) 1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ... 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ... 第28篇 如何.net中實現高效可靠數據同步api 通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ... 所有分類 NET技術 編程語言 軟件設計 WEB前端 手機開發 數據庫技術 操作系統