err的翻譯是

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

前面啰嗦得太多，我再把問題精簡一下：

如何設計詞索引，使得 —— 若 將來 改進了分詞算法，在不重建索引的情況下，搜索結果也能改進？

例如，當詞典沒有“區(qū)塊鏈”一詞時，搜索結果可能包含大量“區(qū)塊”和“鏈”兩個詞的文檔；當把“區(qū)塊鏈”加入詞典后，在不重建索引的情況下，立即就能找到包含“區(qū)塊鏈”的文檔，排名在包含“區(qū)塊”和“鏈”兩個詞的文檔前面。

用 IDbCommand.Parameters 來加參數(shù)最安全，還簡單。。
https://msdn.microsoft.com/en...

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

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

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

我試著開了100個進程去跑，如果遍歷1000w個，從中篩選出我要的分區(qū)，按一個進程遍歷3條/s，大概需要一天多。時間上對于我當前項目是可以忍受的，但是這樣遍歷確實背離了初衷

你試試用systemctl這個命令，這個問題可以去deepin bbs論壇提問的。
類似于，

systemctl disable mysqld.service

或者是
mysql.service

關于systemctl和chkconfig的用法區(qū)別，可以參照下網(wǎng)上的文章
http://blog.csdn.net/kenhins/...

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

好吧，最后在node mysql官方的issues中找了很多例子，結果發(fā)現(xiàn)如果直接用一條語句的話，很多查詢結果都是返回一個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)
}

返回的結果

得到了全部tag并轉成了字符串類型

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

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

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

主鍵，用戶ID，關注的用戶ID，關注時間

查詢關注我的 SELECT * FROM t WHERE 關注的用戶ID=我的用戶ID
查詢我關注的 SELECT * FROM t WHERE 用戶ID=我的用戶ID

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

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

自己瞎寫的一個關于超級初級的數(shù)據(jù)表建立的一個總結

你可以簡單看一下，因為也只是簡略寫，但建立數(shù)據(jù)表，無非是，確立你需要哪些表，而這些你是明確的。然后是確定每個表與表之間的關系，明確后可以建立對應的關聯(lián)甚至關系表。更多的需要根據(jù)具體的需求，以及個人經(jīng)驗積累，或者系統(tǒng)學習吧。我的知識只支持我說道這么一些了。

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

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

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

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

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

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

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

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

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

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

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ù)時通過程序維持約束關系。

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

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

使用外鍵約束缺點：

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

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

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

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

當然，如果你要是想學習 sqlalchemy， 可以看看我的這個項目 sql_to_sqlalchemy

使用 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)