SELECT filed ? WHRER xxx = #{xxx,jdbcType=VARCHAR}
這樣就行了, 用#可以防止SQL注入，如果用#報錯可以 改為使用$ 即 ${xxx,jdbcType=VARCHAR}
詳細(xì)功能可以自己查一下。

設(shè)置一個定時器，剛開始讓所有的table的div都顯示，在頁面打開若干秒或者毫秒之后，讓不該顯示的div隱藏就好了hide（），目前完美解決，后續(xù)有問題再續(xù)問

不輸入的話不就是null了嗎？

err的翻譯是

The API configuration file does not exist
API配置文件不存在
我建議你直接找后端小伙伴解決這個問題

使用 case when 語句

SELECT            
    case          
    when day =6 then pic_1
    when day =9 then pic_2
    else ‘’      
    end                 
from   table     

示例:

mysql> select * from user;
+----+------+-------+-------+
| id | day  | pic_1 | pic_2 |
+----+------+-------+-------+
|  1 |    6 | a     | b     |
|  2 |    9 | a     | b     |
+----+------+-------+-------+
2 rows in set (0.00 sec)

mysql> SELECT id, day, case when day=6 then pic_1 when day=9 then pic_2  else  pic_1  end as pic from   user;
+----+------+------+
| id | day  | pic  |
+----+------+------+
|  1 |    6 | a    |
|  2 |    9 | b    |
+----+------+------+
2 rows in set (0.00 sec)

具體您可以參考下其他的升級教程。
參考一：同平臺升級 oracle 10 到 oracle11g的一些考慮和實際操作

參考二：ORACLE11G R2 升級到ORACLE12C 圖文指南

從調(diào)試工具比如gdb那拿到的結(jié)果有時不能保證是正確的。至于這到底是為什么，這也許是gdb的問題，在深入的話我也不了解了（如果有人知道的話，還請在評論區(qū)指教）。這也是為什么有的時候用IDE的單步跟蹤查看變量值可能是不正確的。

如果打log的話，就可以保證完全正確了。

好吧，最后在node mysql官方的issues中找了很多例子，結(jié)果發(fā)現(xiàn)如果直接用一條語句的話，很多查詢結(jié)果都是返回一個json或object而不是一個array，所以我最后的做法是這樣

SELECT
posts.post_id,
posts.post_title,
GROUP_CONCAT(tags.tag_name) as tags
FROM posts
LEFT JOIN tags ON posts.post_id = tags.post_id
GROUP BY posts.post_id
LIMIT 0,10

node _sql

const getLists = async (page) => {
  let _sql = `SELECT
              posts.*,
              GROUP_CONCAT(tags.tag_name) as tags
              FROM posts
              LEFT JOIN tags ON posts.post_id = tags.post_id
              GROUP BY posts.post_id
              LIMIT ${(page - 1) * 10},10`
  return dbquery(_sql)
}

返回的結(jié)果

得到了全部tag并轉(zhuǎn)成了字符串類型

hibernate的查詢是用query對象來進行的，即Query query=session.createQuery(sql)，在對query遍歷或者直接轉(zhuǎn)list就行。

limit n,m，表示起始值為n，然后取出m個記錄。如果batch size為25，那么可以：
limit 25,limit 25,25,limit50,25 ... 依次下去，默認(rèn)按照表的主鍵id升序排列，每次記錄最大的已處理記錄的主鍵id（這里基于了一個假設(shè)，此表是自增主鍵）

如果此表沒有新增記錄，以上方法肯定沒問題，但是如果此表有多個事務(wù)并發(fā)寫入，可能會導(dǎo)致大id記錄先于小id記錄（兩個事務(wù)）被處理，導(dǎo)致這部分小id記錄永遠(yuǎn)也不會被處理到。

問題中使用post_date其實也會有這個問題，無法保證post_date小的數(shù)據(jù)記錄一定先于post_date大的記錄先入庫。insert時間早，id小的記錄并不一定早于id大的記錄插入至數(shù)據(jù)庫。此完全取決于事務(wù)的提交時間。

你所描述的方法是按需加載

WHERE 1=1 and out_status = 0 and name != '' and name is not null

update一下pip應(yīng)該就好了。解釋在這：https://stackoverflow.com/que...

都說互聯(lián)網(wǎng)開發(fā)盡量不用外鍵，那么這里的不用外鍵到底代表的啥意思呢？

這里的外鍵指的數(shù)據(jù)庫的外鍵約束。

不用外鍵約束。比如刪除一張表中的數(shù)據(jù)時，如果要級聯(lián)刪除另一張表中關(guān)聯(lián)的數(shù)據(jù)，以往是由數(shù)據(jù)庫來級聯(lián)約束的，現(xiàn)在應(yīng)該將其移到程序中由程序來保持?jǐn)?shù)據(jù)的一致性。

是的。外鍵這種約束關(guān)系不在由數(shù)據(jù)庫幫你保持維護，由應(yīng)用程序維護。

外鍵的定義就是在一個表中的字段是另外一張表中的主鍵。如果僅按照"不使用外鍵"這幾個字的字面理解，就是要把外鍵字段抽取出來放在一張中間表中。簡單說就是都當(dāng)成多對多來處理。

不是的。怎么建表還是和原來一樣，只不過在需要建立外鍵約束的地方不建立外鍵約束而已。

比如我們原來建表語句是這樣的：

CREATE TABLE `user` (
  `user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `user_name` varchar(50) NOT NULL DEFAULT '' COMMENT '用戶名',
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `order` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `total_price` decimal(10,2) NOT NULL DEFAULT '0.00',
  `user_id` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `for_indx_user_id` (`user_id`),
  CONSTRAINT `for_indx_user_id` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

不是用外鍵約束后：

CREATE TABLE `user` (
  `user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `user_name` varchar(50) NOT NULL DEFAULT '' COMMENT '用戶名',
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `order` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `total_price` decimal(10,2) NOT NULL DEFAULT '0.00',
  `user_id` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

不適用外鍵約束后，為了加快查詢我們通常會給不建立外鍵約束的字段添加一個索引。

CREATE TABLE `order` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `total_price` decimal(10,2) NOT NULL DEFAULT '0.00',
  `user_id` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如果你理解了，你下面的問題就自然而然不存在了。

避免使用外鍵，可以在插入數(shù)據(jù)時通過程序維持約束關(guān)系。

使用外鍵約束優(yōu)點：

• 外鍵可節(jié)省開發(fā)量
• 外鍵能約束數(shù)據(jù)有效性，非法數(shù)據(jù)不能插入

使用外鍵約束缺點：

• 有額外開銷
• 主鍵表被鎖定時，會引發(fā)外鍵表也被鎖
• 刪除主鍵表的數(shù)據(jù)時，需先刪除外鍵表的數(shù)據(jù)
• 修改外鍵表字段時，需重建外鍵約束

實際開發(fā)中，一般不會建立外鍵約束。

你可以了解下trigger的用法，但是呢，我個人建議是不要用觸發(fā)器好，用代碼邏輯實現(xiàn)，這樣效率上會更高點，而不會給MySQL服務(wù)器造成一定的壓力，如果流量特別大的話

1、時間檢索結(jié)果集小的話就一個start_time單列索引就夠了，force一下索引，因為group by會引導(dǎo)mysql走group by字段的索引或者直接全掃。
2、看表名，你這應(yīng)該是一個分表，如果時間范圍直接覆蓋了大部分表數(shù)據(jù)的話什么索引都不用了，全表掃吧，什么三個字段兩個字段加索引并沒有什么用，時間范圍加group by字段的復(fù)合索引也只用到了時間字段，只有g(shù)roup by字段的索引就是掃了全表，除非用索引覆蓋

主鍵，用戶ID，關(guān)注的用戶ID，關(guān)注時間

查詢關(guān)注我的 SELECT * FROM t WHERE 關(guān)注的用戶ID=我的用戶ID
查詢我關(guān)注的 SELECT * FROM t WHERE 用戶ID=我的用戶ID

sql to sqlalchemy 項目，這是基于 MYSQL 的，你要是通過這個練習(xí)，你的 sqlalchemy 會飛起來。如果你真需要，我可以給你MySQL的用戶和密碼。別問我是誰，我是雷鋒。

你可以看看這篇文章 使 sqlalchemy 數(shù)據(jù) json 化。

當(dāng)然，如果你要是想學(xué)習(xí) sqlalchemy， 可以看看我的這個項目 sql_to_sqlalchemy

py3 必須使用絕對引用了

一般的格式是 from . import 模塊名，最好養(yǎng)成這個習(xí)慣