After the mysql library is used, the memory is high

[tgy3300]

use mysql::{
    prelude::Queryable,
    OptsBuilder, Pool, PooledConn, Row,
};

#[tokio::main]
async fn main() {
    let cli = get_client(&TidbConfig {
        host: "127.0.0.1".to_string(),
        user: "root".to_string(),
        pwd: "123456".to_string(),
        db_name: "shop".to_string(),
        port: 3306,
    });
    App::new(cli).run().await
}

struct App {
    client: PooledConn,
}
impl App {
    fn new(client: PooledConn) -> Self {
        Self { client }
    }
    async fn run(&mut self) {
        let res: Option<Row> = self.client.query_first("select * from company").unwrap();
        println!("-----{:#?}", res);

        tokio::select! {
            _ = tokio::signal::ctrl_c() => {},
        }
    }
}

fn get_client(c: &TidbConfig) -> PooledConn {
    let opts = OptsBuilder::new()
        .ip_or_hostname(Some(&c.host))
        .user(Some(&c.user))
        .pass(Some(&c.pwd))
        .db_name(Some(&c.db_name))
        .tcp_port(c.port);
    let pool = Pool::new(opts).unwrap();
    let conn = pool.get_conn().unwrap();
    conn
}

struct TidbConfig {
    host: String,
    user: String,
    pwd: String,
    db_name: String,
    port: u16,
}

Through the cargo build -r mission package out of the package, after starting, why the memory is so high, after debugging, is the reason for mysql library, I have any problems with the use of mysql library?

[blackbeam]

Hi. I have to point out that few things are seriously wrong with your code:

1. You are using synchronous mysql driver with asynchronous runtime (tokio) — you should ether switch to mysql_async or properly wrap blocking calls into spawn_blocking.
2. Pool created for no reason — you should either use bare Conn or use single Pool to manage DB connections.

Regarding the memory usage in your case — I've tried your code as is on Mac and have only 3,7 MB of reported memory usage.

Regarding memory usage in general — few things may add here:

1. Connection stream internal buffer may grow up to max_allowed_packet setting defined on the server side
2. If Pool is in use then you should note that every established connection in the pool will have it's own stream with its own internal buffer, so the total memory consumption may grow up to max_allowed_packet * number of active connections in the pool
3. The library also have a general purpose buffer pool that you can tweak or turn off — see the Buffer Pool section in the docs.